MCP in Production: What the Model Context Protocol Actually Solves

If you’re wiring an LLM into a real product, you’ve already hit the integration tax. Every model you support times every tool it needs becomes its own bespoke adapter, its own auth handling, its own schema. The Model Context Protocol (MCP) is the open standard, introduced by Anthropic in November 2024, that collapses that tax. It defines one way for an application to expose tools, data, and prompts to any compatible model, so you build the connection once instead of once per pairing.

That’s the honest version of the pitch. MCP solves a genuine plumbing problem. It does not make your agent smarter, and it does not make a badly-scoped tool safe to hand a model. We integrate AI into existing workflows for a living, and the protocol only earns its place when the tools and permissions underneath it are already sound. This piece is the skeptical practitioner’s read: what MCP actually solves, what it doesn’t, and what breaks when it meets production.

What does the Model Context Protocol actually solve?

MCP solves the N-by-M integration problem. Connecting N AI applications to M external tools used to need N times M custom integrations. With MCP, each application implements one client and each tool implements one server, so the total drops to N plus M. The official docs frame it as a USB-C port for AI: one standard socket, many plugs.

The payoff is reuse. A server you write for your Postgres database or your ticketing system works with Claude, ChatGPT, Cursor, and anything else that speaks the protocol. That portability is why adoption moved fast. OpenAI adopted MCP across its Agents SDK and ChatGPT in March 2025, Google confirmed Gemini support weeks later, and by December 2025 the protocol had been donated to a Linux Foundation body co-founded by Anthropic, Block, and OpenAI.

The three things a server exposes

• Tools the model can call to take an action (query a database, open a ticket).
• Resources the model can read for context (files, records, documents).
• Prompts, reusable templates a server offers for common workflows.

How is MCP different from function calling?

They sit at different layers, and the confusion costs teams real time. Function calling is how a model expresses what it wants to do: it returns a structured request naming a tool and its arguments. MCP is how that request gets executed and where the tool lives. Function calling embeds the tool in your app; MCP moves it to a shared server behind a network hop.

Which means they’re complementary, not rival choices. Most production systems use both: function calling for logic that only one agent needs, MCP for infrastructure many clients share. If you have fewer than five tools and one model provider, plain function calling is often 20 to 30 lines of code and the network hop buys you nothing. We make the same call when a client asks us to choose an agent stack: match the mechanism to the blast radius, not the hype.

What does MCP not solve?

MCP is packaging and transport. It standardises the envelope, not the intelligence inside it. A model connected to forty tools over MCP still has to choose the right one, pass sane arguments, and recover when the call fails. That’s a reasoning and evaluation problem, and it’s where most agents actually break. We’ve measured tool-calling reliability across frameworks, and a clean protocol does nothing to lift a model that fumbles tool selection under load.

It also doesn’t fix the tool. If a server exposes a database action with broad write access, MCP forwards that action faithfully to whatever asks. The protocol is a courier. It doesn’t audit what’s in the package. This is the same lesson we keep relearning about why AI features fail even when the model works: the failure is almost never the model, it’s the integration around it. MCP standardises that integration surface, which is useful, but standardising a weak boundary just makes the weakness portable.

What breaks when MCP meets production?

Adopting a protocol adds moving parts. Here are the ones we watch before putting an MCP server in front of anything that matters.

Prompt injection through tool descriptions

This is the sharp edge. A model reads the descriptions a server advertises, and those descriptions are attacker-influenceable if the server ingests untrusted content. A 2026 threat-modeling study found 5 of 7 MCP clients did not statically validate server-supplied tool metadata, letting poisoned descriptions flow straight into the model’s context. The Supabase Cursor incident in mid-2025 showed the live version: a privileged agent processed support tickets containing embedded SQL and exfiltrated integration tokens.

Auth, versioning, and latency

• Auth. A shared server needs its own identity, scoping, and least-privilege model. A gateway that logs which agent called which tool with what arguments is the difference between an audit and a shrug.
• Versioning. The spec is still moving; the November 2025 release added statelessness and server identity. A server your client depended on can change under you.
• Latency. Every MCP call is a network hop to a separate process. For chatty agents that adds up, and it compounds the delays we’ve traced in latency-sensitive systems.
• Over-adoption. Wrapping every internal function in a server because MCP is trendy adds surface area for no reuse benefit.

Build a server or just adopt one?

Adopt an existing server when a reputable one already covers your tool and you trust its scoping. Build your own when the tool is proprietary, touches sensitive data, or needs permissions you won’t hand to third-party code. Either way, treat every server as an untrusted boundary: validate tool descriptions, scope credentials tightly, and log every call. This is the same discipline we bring to introducing AI into existing systems and to deciding where AI fits in an architecture at all.

MCP is a good standard solving a real problem. It’s worth adopting when tools are genuinely reused across clients and the permissions underneath are already tight. It’s not a shortcut past the hard parts: tool reliability, scoping, and knowing which actions a model should never be allowed to take. If you’re weighing MCP for a production workflow and want a second read on the boundaries, start with the parts the demos skip. No pitch, just a conversation.

Frequently Asked Questions

Is the Model Context Protocol just function calling with extra steps?

No. Function calling is how a model expresses which tool it wants and with what arguments. MCP standardises how that request is executed and where the tool lives, on a shared server any compatible client can reach. They operate at different layers and most production systems use both: function calling for app-specific logic, MCP for tools multiple clients reuse.

Does adopting MCP make my AI agent more reliable?

Not on its own. MCP standardises the integration surface, not the model’s judgement. The agent still has to select the right tool, pass valid arguments, and recover from failures. Those are reasoning and evaluation problems. A clean protocol makes tools easier to connect, but tool-calling reliability under real inputs is a separate thing you still have to measure and design for.

What is the main security risk with MCP servers?

Tool poisoning and prompt injection through tool descriptions. A model reads the metadata a server advertises, and if the server handles untrusted input, an attacker can smuggle instructions into that metadata. One 2026 study found 5 of 7 clients did not statically validate server-supplied descriptions. Treat every server as an untrusted boundary: validate descriptions, scope credentials, and log every call.

Should I build my own MCP server or adopt an existing one?

Adopt an existing server when a reputable one covers your tool and you trust its scoping. Build your own when the tool is proprietary, touches sensitive data, or needs permissions you would not grant to third-party code. In both cases apply least privilege and audit logging, because MCP forwards whatever action a server exposes without judging it.