title: "MCP Is Reshaping Microservices — And Most Teams Haven't Noticed Yet" date: "2026-03-14" description: "Model Context Protocol isn't just a tool-calling standard. It's a new connectivity layer that's quietly rerouting how agentic systems replace — or replace the need for — microservices." tags: ["AI/Agentic", "Platform"]
There's a pattern I keep seeing in production agentic systems: teams reach for a microservice when what they actually need is an MCP server. It's not that microservices are wrong — it's that the problem they're solving is changing shape.
Model Context Protocol (MCP) is an open standard, originally from Anthropic and now donated to the Linux Foundation under the AAIF alongside OpenAI, Google, and Microsoft. The consortium backing matters less than what the spec actually does: it gives agents a standardized way to reach external context, tools, and data — without you having to bake that plumbing into your model or orchestration layer.
That sounds modest. It isn't.
What MCP Actually Is
MCP defines a client-server protocol where an agent (the client) connects to an MCP server that exposes capabilities: tools the agent can call, resources it can read, and prompts it can use as templates. The server handles auth, data access, and execution. The agent handles reasoning and sequencing.
The canonical example is filesystem access. Instead of giving an agent raw exec calls or a fat SDK, you run an MCP server that exposes readFile, writeFile, listDir as typed tools with defined schemas. The agent calls those tools. The server enforces what's accessible. The boundary is explicit.
But that same pattern applies to anything with a boundary: your database, your internal APIs, your GitHub repos, your Slack workspace, your Stripe account. Each of those becomes an MCP server. Each agent gets exactly the servers it needs — scoped, auditable, not global.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace/src"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
}
}
}That config scopes the filesystem server to /workspace/src — not the whole disk. That's not incidental. Tight scoping is the whole game.
The Three Patterns That Are Replacing Microservices
I'm not saying microservices are dead. I'm saying there are specific things we used to build as microservices that MCP servers do better — especially inside agentic workflows.
Pattern 1: Capability Servers Instead of Internal APIs
The classic microservices move: you have a data service, you build a REST API, every consumer calls it. The API is the contract. Versioning, auth middleware, rate limiting, error handling — all of it lives in that service.
In an agentic system, you still want that boundary. But an agent calling a REST API means your agent needs to understand the API's schema, handle HTTP errors, parse responses, retry on 429s, and re-encode all of that reasoning into tool calls. It's possible. It's also unnecessary friction.
An MCP server wraps that same service and exposes typed tools instead. The agent calls get_customer_order_history(customer_id: "xyz123") — not GET /api/v2/orders?customerId=xyz123&limit=50&sort=desc. The intent is clearer, the schema is agent-native, and the server handles the HTTP layer underneath.
You're not removing the service. You're changing how agents reach it.
Pattern 2: Scoped Context Injection Instead of API Gateways
The second pattern is about context, not operations.
A common agentic failure mode: you give an agent access to everything, then wonder why it does unexpected things. Wide access is a prompt vulnerability, not a feature. If your agent has a tool that can write to any table in your database, you're one hallucinated table name away from a bad day.
MCP servers fix this architecturally. You scope each server to exactly what that agent legitimately needs. A billing agent gets a billing MCP server. An infra agent gets a k8s MCP server. No agent gets access to tools it has no business calling.
In SteerMesh, we make this explicit per agent:
const result = await steermesh.run({
goal: 'Generate and post the weekly deployment summary',
agents: [
{
role: 'data-collector',
model: 'auto',
instructions: '@.agents/deployment-collector.md',
mcp: ['github', 'datadog'],
},
{
role: 'writer',
model: 'claude-opus-4-6',
instructions: '@.agents/report-writer.md',
mcp: ['slack'],
},
],
state: { week: '2026-W11', channel: '#eng-deploys' },
})The data-collector can see GitHub and Datadog. The writer can post to Slack. Neither can do the other's job — not because of application-layer auth checks, but because they literally don't have the tools. The architecture is the policy.
Pattern 3: Audit Trails as a First-Class Concern
This is the one that most teams ignore until something goes wrong.
In a traditional microservice setup, you get audit trails by logging requests and responses at the service boundary. Works fine when humans are the callers — they follow predictable patterns, they make bounded numbers of calls, and when something goes wrong there's usually a user session to correlate against.
Agents are different. They're autonomous. They make decisions you didn't explicitly anticipate. They chain tool calls in sequences that weren't part of the original prompt. And when something goes wrong — when an agent modified a record it shouldn't have touched — you need to be able to reconstruct why it did that, not just what it did.
MCP servers give you a clean seam for this. Every tool invocation goes through the server. The server logs the caller, the arguments, the response, and the timestamp. Combined with the agent's trace — which reasoning step triggered which tool call — you get a full audit chain.
Without this, you're left correlating HTTP logs from ten different services and guessing which agent run produced which requests. That's not a sustainable debugging strategy when you have dozens of agents running concurrently.
The Security Problem Nobody Is Talking About Enough
Tool poisoning is real and underestimated.
The attack works like this: you connect your agent to an MCP server that someone else controls (or that you control but has been compromised). That server's tool descriptions contain hidden instructions — injected into the schema that the agent reads when it discovers available tools. The agent, treating tool descriptions as trusted context, follows those instructions.
This is prompt injection at the protocol layer. And it's nastier than browser XSS because it's invisible to users and hard to audit by diff.
The mitigations are the same boring engineering practices that work everywhere else:
- Only run MCP servers you control or have vetted. The npm ecosystem for MCP servers is early and fast-moving. "npx -y @some-vendor/mcp-server" is a supply chain decision, not just a convenience.
- Pin versions.
@modelcontextprotocol/server-github@0.6.2, not@modelcontextprotocol/server-github@latest. Floating versions mean your tool schema can change out from under you. - Review tool schemas before they reach agents. Treat the tools exposed by an MCP server the same way you'd treat a dependency in your package.json — you should know what's in there.
- Scope aggressively. The smallest possible surface area for each agent. If the writer agent only needs to post to Slack, its MCP config should contain exactly one server and no others.
Steering Files + MCP = The Full Context Layer
Here's the synthesis that I think matters most.
A steering file tells an agent how to reason. An MCP server gives it what to act on. Together, they form the complete context layer for an agentic system — the standing instructions and the scoped capabilities that define what this agent is and what it can do.
Neither is sufficient alone. A well-written steering file without scoped tool access is a liability — the agent reasons well but can reach things it shouldn't. Scoped MCP servers without good steering is noise — the agent has the right tools but uses them erratically.
This is how you get reliable agents in production: clear steering, tight scope, auditable calls. Not fine-tuned models. Not magic prompts. Just engineering discipline applied to the right abstractions.
The microservices analogy breaks down here, actually. Microservices were about decomposing computation. MCP is about decomposing access. The agent does the computation — that's the whole point. What you're designing is the boundary of what it can reach and the rules it carries when it does.
The Short Version
MCP isn't a chatbot feature. It's the connectivity standard for agentic systems, and now that it's under neutral governance with buy-in from every major AI lab, it's the one to build on.
The teams winning with this right now are doing three things: scoping MCP servers tightly per agent (not one god-server for all), treating tool schemas as security surfaces (not just convenience), and combining MCP with steering files to define both the how and the what of every agent.
The teams who are going to struggle are the ones still thinking about this as "adding tools to the LLM." The mental model shift is from enhanced chatbots to scoped microservice consumers — agents that have explicit, auditable, version-controlled access to exactly what they need and nothing more.
More on how SteerMesh handles MCP routing and server discovery in a future post.