Connecting existing systems to AI agents with MCP: 3 strategies we run in production

By **Isabele Santos, co-written with **Fernando Junior.

Today we use three possible paths, which let us make good use of what MCP offers. MCP (Model Context Protocol) is an open protocol created by Anthropic and now adopted by the main players in the market. In practice, that has made it the "USB-C" of enterprise AI: instead of building a handcrafted connector for every model–system pair, you build an MCP server once and any compatible client can connect to it.

The protocol exposes three primitives: Resources (data the model can read for context), Prompts (reusable templates for standardized flows) and Tools (functions the model can invoke to take real actions — fetching a record, firing an event, changing a status).

We've implemented three strategies in production over the last year, and that has been cutting costs and headaches. Which raises the question: what does it cost, today, not to implement this protocol? The MIT study (Project NANDA) showed that about 95% of enterprise generative AI pilots deliver no measurable P&L impact — pointing to enterprise integration failures as the core problem, not model quality. That's against an estimated US$30–40 billion invested in GenAI, with 95% of organizations getting zero return. In most cases, the bottleneck is the difficulty of maintaining many separate integrations, which cost time and money besides being inefficient. It becomes clear that one of today's bottlenecks in enterprise AI is integrating models with systems, not the quality of the models themselves. (Source: "The GenAI Divide: State of AI in Business 2025", MIT Project NANDA, via Fortune)

Note: The study attributes the failure to the "learning gap" and to integration with real workflows.

So how did our team choose to get around this problem? Precisely by applying three strategies, which vary in isolation and effort, presented by Fernando Junior, our Development Lead, based on what we run in production.

— Isabele Santos

Strategy 1 — Proxy + Swagger

Data flow: LLM → MCP Server (acting as a proxy) → existing HTTP REST API.

Automation: the server reads Swagger/OpenAPI files natively and generates the LLM "tools" 100% automatically.

Zero cost on the legacy side: no change needed in the original backend code.

Ideal scenario: perfect for fast prototyping, integrating external APIs or plugging in legacy systems where code changes are complex.

The limit of this approach: the quality of the generated tools is the quality of your OpenAPI documentation. Poorly described APIs produce tools the model uses poorly. It's the right strategy to get started in days — not to be a product's final destination.

Strategy 2 — Simple Project (Read-Only)

Lean micro-server: we build simplified projects in which the MCP Server skips the deep, complex layers of a typical web application. It focuses exclusively on exposing Tools with strict, predefined SQL scripts, eliminating the complexity of HTTP routing.

Safe execution (read): every instruction made available to the AI is guaranteed to be limited to read-only operations on the database. This approach creates a fast, efficient foundation for reporting, context validation and conversational BI with no structural risk.

— Fernando Junior

This is the structural answer to the question every manager asks: "what if the AI deletes my database?". Here the guarantee isn't an instruction in the prompt asking the AI to behave — it's architecture. The model only has access to predefined, read-only queries, and nothing else exists for it. Security by construction, not by trust.

— Isabele Santos

Strategy 3 — Integrated via Clean Architecture

Multiple entry points: our modern architecture lets the same business rule be triggered both through a traditional HTTP Controller and through the new MCP channel.

MCP adapter: the MCP Tool Handler is written as just a new adapter in the interface layer of our Clean Architecture, encapsulating the protocol's complexity.

Unchanged rules: the motto is "New door, same house". Our Use Cases and Core Domain stay completely unchanged, safe and reused with no duplicated logic.

MCP doesn't break what already exists: MCP acts as just one more side entrance, running in parallel with the existing controllers. We keep the Separation of Concerns principle intact, isolating human clients from AI agents. Clean Architecture lets us guarantee that the business rule (Use Cases) can't tell the difference between a conventional HTTP call and an execution generated by the LLM.

After implementation: what we learned running MCP in production

Putting an MCP server online is the easy part. What sustains operations comes afterwards — and three fronts deserve attention because they're exactly what separates those who have operated it from those who have only read the docs:

1. Security starts at the connection, not in the prompt. In our implementation, strict client identification happens when the connection to the server is initialized, via an API Key sent in an HTTP header. And authorization is dynamic: the data exposed — and even which Tools are listed — is filtered according to the permissions of the connected agent. A BI agent doesn't see the same tools as an operations agent; it doesn't even know they exist. The natural roadmap for this layer is full adoption of OAuth 2.0 and JWTs, the market standard.

2. Validate the server in isolation before plugging in the LLM. The best workflow practice we've adopted: test Tools and Resources locally with the MCP Inspector (the official debugging UI, which starts with a single npm command) before attaching the server to any LLM client. The Inspector lets you run each Tool with a click, fill in the input payload, analyze the output array and — crucially — inspect the raw JSON-RPC traffic in the History tab. Debugging the protocol together with model behavior means adding up two uncertainties; separating them saves hours.

3. Errors are part of the contract. MCP's return format includes the isError: true flag for recoverable failures — and that changes the game: the model interprets the failure and can fix its own arguments and try again, with no human intervention. Designing good error messages stopped being cosmetic; it became part of the interface with the agent.

— Fernando Junior

The most valuable side effect of all this is portability. An MCP server built today works tomorrow in any ecosystem that adopts the protocol, from Claude Desktop to IDEs like Cursor and VS Code, and even our own applications. Integration investment is no longer thrown away every time you switch model vendors.

The MIT diagnosis doesn't say generative AI failed. It says integration failed. And integration is an engineering problem with a known solution: a single standard instead of dozens of handcrafted connectors. The three strategies we've presented aren't theory; they're the three steps we use in production, from a prototype in days (Proxy + Swagger) to safe data access (Read-Only) to the long-term product (Clean Architecture). The decision rule is simple: the more mature and critical the system, the more structural the integration should be.

Whoever builds this foundation now isn't betting on a vendor — they're building the door through which any AI agent will enter their operation. That's exactly the foundation we brought into Zihin: the platform speaks MCP from day one, with a remote server ready to connect your systems to agents without a handcrafted integration project — with governance and security from the connection onward. If your team is stuck in the pilot phase, the problem probably isn't the model, it's the bridge. Book a diagnostic and see in practice how to plug your data and actions into governed AI agents.

— Isabele Santos

Q&A

Tip: Where do I start implementing MCP in my company?
With the lowest-risk strategy: an MCP proxy over an existing, well-documented API (Swagger/OpenAPI), or a read-only micro-server over a reporting database. Both deliver value in days, without touching legacy code, and serve as a learning step before structural integrations.

Note: Does MCP only work with Claude?
No. MCP was born at Anthropic, but it's an open protocol adopted by the main AI ecosystems in the market. An MCP server built today works with any compatible client — models, IDEs and your own applications.

Warning: Is it safe to give an AI access to the database?
It depends on how the access is built. With a read-only MCP server exposing only predefined queries, the AI structurally can't change anything — the limitation lives in the architecture, not in behavioral instructions. For writes, the path is to expose specific Use Cases with per-agent authorization, never direct database access.

Note: Do I need to rewrite my systems to use MCP?
No. The three strategies in this article exist precisely to avoid that: a proxy over existing APIs (zero change), a parallel micro-server (zero change) or a new adapter in the interface layer (minimal, isolated change). The business rule stays intact.

Sources

• The GenAI Divide: State of AI in Business 2025 — MIT Project NANDA (Fortune coverage)

Originally published in Portuguese on the Zihin blog. I work at Zihin, which connects AI agents to a company's systems and processes, with permissions, human approvals and cost tracking.