As a principal engineer, what are the key design, security, and operational trade-offs when adopting MCP versus in-process @Tool beans in a Spring AI system?

## Framing the decision Both approaches ultimately produce Spring AI `ToolCallback`s the model can invoke. The question is **where the tool executes and who owns the boundary**. - **In-process `@Tool` beans**: methods in your app, wired straight into `ChatClient`. No network, no separate process, in-JVM types, in-JVM security context. - **MCP**: tools live behind an MCP server (yours or someone else's), reached over stdio or HTTP/SSE, discovered dynamically. ## What MCP buys you 1. **Interoperability**: publish once, and any MCP host (IDEs, assistants, other services) can use your tools — and you can consume third-party/other-team servers with config, not code. 2. **Decoupling & reuse**: the tool implementation evolves independently of the LLM app; multiple consumers share one implementation. 3. **Polyglot / process isolation**: a tool server can be written in another language or run sandboxed as a subprocess. ## What it costs 1. **Distributed-systems overhead**: each `tools/call` is remote — latency, timeouts, retries, circuit-breaking, partial availability. Local method calls have none of this. 2. **Security & trust** (the big one): - MCP standardizes **transport and discovery, not authentication/authorization** — you must secure HTTP endpoints (auth, TLS, rate limits) and isolate stdio subprocesses (they run real code with your process's privileges by default). - **Untrusted tool output**: results from an external server flow back into the prompt — a **prompt-injection / data-exfiltration** vector. Treat tool results as untrusted input; constrain what tools can do. - **Supply-chain risk**: consuming a third-party MCP server means trusting its code/behavior; govern which servers are allowed. 3. **Naming & versioning governance**: aggregating multiple servers risks **tool-name collisions**; you need namespacing/prefixing and a policy for evolving the exposed tool surface (descriptions, schemas, versions) without breaking consumers. 4. **Consistency**: pick SYNC or ASYNC end-to-end (blocking MVC vs reactive WebFlux) to avoid thread-starvation and mixed-model complexity. 5. **Observability**: you now need tracing/metrics across the hop to debug why a tool was called, timed out, or returned garbage. ## When to choose which - **Prefer in-process `@Tool`** when tools are internal to one app, low-latency, and don't need external reuse — it's simpler, faster, and keeps the trust boundary inside the JVM. - **Prefer MCP** when you cross a **process, team, or vendor boundary**: publishing a shared capability surface, consuming third-party tools, isolating risky/polyglot tools, or letting external hosts use your capabilities. ## Principal-level guardrails - Establish an **allowlist** of MCP servers and a review process for adding new ones. - Enforce **input validation and least-privilege** in every exposed `@Tool`; never assume the caller (or the model) is benign. - Define **tool naming/namespacing** conventions and **surface versioning**. - Standardize **timeout/retry/circuit-breaker** policy and **tracing** for tool calls. - Decide **sync vs async** at the platform level and keep transports aligned. - Consider **blast radius**: an external tool result can steer the model — sandbox side effects and confirm high-impact actions. ## Bottom line MCP is an integration and interoperability play with a distributed-systems and security tax. Adopt it where the boundary genuinely exists; otherwise keep tools in-process.