A Claude Code session can produce a perfectly plausible Spring patch while reading the wrong configuration file, copying an environment-specific URL into a test, or treating a missing JSON field as valid input. Spring Tools 5.2 makes Spring project context available through an embedded MCP server, but the safety boundary you need is a disposable workspace—not an optimistic prompt.

ADTmag’s release coverage says Spring Tools 5.2.0 adds experimental Claude Code plugin support, Spring AI support, and an embedded MCP server for exposing a Spring project. That is useful because a Spring-aware tool can reduce the “where is this bean configured?” scavenger hunt. It is also precisely why context must be treated as an input with a blast radius: Spring repositories commonly contain deployment descriptors, generated files, local profiles, and secrets-adjacent configuration beside ordinary Java code.

The release information currently available does not establish a stable, public setup path or a granular MCP file-permission model. So this is deliberately a workflow guide, not a click-by-click product tutorial that invents menu labels. The goal is to make one small Spring Boot change safely, using Claude Code only after the exposed workspace is made safe to inspect.

1. Start with the real boundary: the filesystem Claude Code can see

An MCP server can provide structured project context, but it is not automatically a sandbox for the AI client. Claude Code also operates in the local directory from which you start it and may be able to inspect files available to your user account, subject to its own permissions and configuration. “Only discuss src/main/java” is a request, not access control.

The available Spring Tools 5.2 announcement does not say whether its embedded server:

  • exposes files as individual MCP resources, search results, project metadata, or a mixture;
  • is read-only, can invoke edits, or can trigger build and run actions;
  • respects .gitignore, follows symlinks, or resolves files outside the repository;
  • can enforce a per-directory allowlist; or
  • uses the open IDE project, the process working directory, or another definition of workspace.

Until those details are documented and verified in your installed build, assume that opening a repository can reveal every readable file under it. The enforceable control is therefore workspace isolation: give the assistant a directory that does not contain secrets or unrelated material in the first place.

For a small change, create a separate Git worktree or sanitized clone. A worktree preserves repository history while keeping the AI session’s working directory separate from the branch where you do normal development.

git fetch origin
git worktree add ../orders-ai-review -b ai/quantity-validation origin/main
cd ../orders-ai-review
git status --short

If your repository keeps local secrets in tracked templates, a worktree is not enough. Use a sanitized clone, remove the unsafe material before launching Claude Code, and do not copy local environment files into it.

git clone --no-local ../orders-service ../orders-ai-sanitized
cd ../orders-ai-sanitized
rm -f .env application-local.yml application-prod.yml
find . -name '*.pem' -o -name '*.p12' -o -name '*credentials*'
git status --short

2. Prepare a minimal Spring project before connecting any assistant

Use a project that can compile and test without your production configuration. The running example is an order endpoint whose request body currently accepts zero items. The desired outcome is narrow: reject quantity: 0, reject a missing quantity, and accept quantity: 1.

Before opening Spring Tools or Claude Code, inspect the candidate workspace yourself.

  • Keep src/main/java, src/test/java, the build file, and non-secret defaults such as application.yml only if they are safe.
  • Exclude or delete .env, cloud credentials, private keys, copied production YAML, database dumps, and shell history.
  • Check symlinks with find -L . -type l. A symlink to a parent directory or home directory defeats a repository-only assumption.
  • Run the baseline test suite before asking for a patch.
find -L . -type l -print
git ls-files | grep -Ei '(^|/)(\.env|.*\.(pem|key|p12)|.*credential.*|.*secret.*)$' || true
./mvnw test

For Spring Boot MVC validation, confirm the application has Bean Validation support. In many Spring Boot applications this comes from spring-boot-starter-validation; do not assume a transitive dependency will remain present after a future dependency change.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-validation</artifactId>
</dependency>

This preparation has a second-order review benefit. If the session is limited to an order-service worktree, a reviewer can explain a proposed change from the source and tests in that worktree. If the assistant also saw an internal deployment file and introduces a new header or URL based on it, the reviewer cannot tell from the diff whether that choice is a legitimate requirement or leaked incidental context. That uncertainty increases review time and can turn a small validation patch into an architecture investigation.

3. Connect Spring Tools 5.2 and Claude Code without pretending the plugin is a sandbox

Spring Tools 5.2’s embedded MCP server and Claude Code integration are described as experimental in the release coverage. Use the connection flow shown by the exact 5.2 build you installed, and verify the project selected in that flow is the isolated worktree—not your original checkout.

The minimum operational sequence is:

  1. Open only ../orders-ai-review or the sanitized clone as the Spring project in Spring Tools.
  2. Use the Spring Tools 5.2 Claude Code/MCP integration supplied by that build to start or connect its embedded server for that project.
  3. Start Claude Code from the same isolated directory, rather than from a parent directory containing several repositories.
  4. Use Claude Code’s MCP status or connection view to confirm the intended Spring Tools server is attached before making a request.
cd ../orders-ai-review
claude

The initial command above establishes the important project-selection fact that you can verify: Claude Code starts in the isolated directory. The exact server command, server name, and configuration location should come from Spring Tools 5.2 itself; the release information available here does not provide them. Do not invent a generic MCP command line or paste a third-party configuration snippet into a production checkout.

Before the first prompt, record what you connected:

  • the Git worktree path;
  • the checked-out commit, from git rev-parse HEAD;
  • the Spring Tools version displayed by the product; and
  • the MCP server name and status displayed by Claude Code or Spring Tools.
pwd
git rev-parse --short HEAD
git status --short

If the tool displays an unexpected workspace name, parent path, or server, stop there. Do not “test” whether it can see sensitive files by asking it to list them.

4. Run a read-only discovery pass before authorizing a patch

The first request should ask for evidence, not implementation. This establishes whether the assistant can locate the request DTO, controller, build dependency, and existing test conventions. It also makes an assistant’s assumptions visible before those assumptions become a diff.

Read-only task. Do not edit files or run commands that modify the workspace.

In this Spring project, identify:
1. the request DTO used by POST /orders,
2. the controller method that receives it,
3. whether Bean Validation is enabled in the build,
4. the existing controller test style, and
5. the smallest files needed to reject missing or zero quantity.

Return file paths, relevant symbols, and a proposed test contract.
Do not inspect files outside this workspace.

A grounded response should look like this, with real paths and symbols rather than general Spring advice:

src/main/java/com/example/orders/CreateOrderRequest.java has int quantity. OrderController#create receives @RequestBody CreateOrderRequest request without @Valid. pom.xml already includes spring-boot-starter-validation. OrderControllerTest uses MockMvc. The minimal change is to use nullable Integer, add @NotNull and @Min(1), add @Valid at the controller boundary, and add MockMvc assertions for 400 and 201.

If the reply cannot name paths and symbols from your repository, treat it as ungrounded. Correct the scope or investigate the connection; do not proceed to “write the code anyway.”

5. Approve one implementation change and test the HTTP contract

Now authorize exactly one outcome. The distinction between int and Integer matters: when JSON omits a primitive int quantity, deserialization can leave it at 0. That makes “missing” indistinguishable from a supplied zero. A nullable Integer lets @NotNull reject missing input and @Min(1) reject zero and negative input.

Implement only the quantity validation change identified above.

Requirements:
- Use Integer quantity, @NotNull, and @Min(1).
- Add @Valid to the controller's @RequestBody parameter.
- Do not change persistence, security, API paths, dependencies, or unrelated files.
- Add MockMvc tests: quantity 0 returns HTTP 400; quantity 1 returns the endpoint's existing success status.
- Preserve the project's existing error-body convention.
Show the diff before any further refactoring.

A compact expected patch has three pieces. Annotation imports are omitted here only to keep the example short.

// CreateOrderRequest.java
public record CreateOrderRequest(
    @NotNull @Min(1) Integer quantity
) {}

// OrderController.java
@PostMapping("/orders")
ResponseEntity<OrderResponse> create(
    @Valid @RequestBody CreateOrderRequest request
) {
    // existing implementation
}
// OrderControllerTest.java
mockMvc.perform(post("/orders")
        .contentType(MediaType.APPLICATION_JSON)
        .content("""{"quantity":0}"""))
    .andExpect(status().isBadRequest())
    .andExpect(jsonPath("$.status").value(400));

mockMvc.perform(post("/orders")
        .contentType(MediaType.APPLICATION_JSON)
        .content("""{"quantity":1}"""))
    .andExpect(status().isCreated());

The exact error payload is application-specific. If your API uses Spring Boot’s default problem details, assert the fields your service has committed to support. If it has a custom error handler, assert its established contract, for example $.code == "VALIDATION_ERROR" and a field error for quantity. Do not assert an English validation message unless that text is intentionally part of your public API.

6. Review, disconnect, and roll back when the context is wrong

Run the build and inspect the patch as a normal code review, not as a reward for a successful prompt. The generated code is acceptable only if every changed line can be explained by the request DTO, controller contract, and tests in the isolated workspace.

git diff --check
git diff -- src/main/java src/test/java pom.xml build.gradle
./mvnw test
git status --short
  • Reject changes to dependency versions, CI configuration, deployment files, or unrelated endpoints for this task.
  • Check that @Valid is on the controller argument. Constraints on a DTO do not automatically validate an incoming MVC request without validation being invoked at the boundary.
  • Test three payloads: omitted quantity, quantity: 0, and quantity: 1.
  • Confirm the 400 response matches the error contract clients actually consume.

If Claude Code appears to see unexpected files, proposes an out-of-scope patch, or produces a change that cannot be explained from the exposed source, take immediate action:

  1. Stop the Claude Code session.
  2. Disconnect or revoke the Spring Tools MCP connection using the integration’s connection/status controls.
  3. Inspect the displayed server configuration, logs, and selected project path if the installed tools make them available.
  4. Discard the patch with git restore ., or remove the disposable worktree entirely.
  5. Create a narrower sanitized workspace and repeat discovery before reconnecting.
git restore .
cd ..
git worktree remove ../orders-ai-review

Use this workflow this week on one request-validation defect, one controller test, and one disposable worktree. Spring Tools’ embedded MCP capability can make Spring structure easier for an assistant to navigate; it does not replace the engineering controls that decide what the assistant is permitted to learn from.