TL;DR
- A model needs access to current records and business tools to complete useful work. A larger context window does not create that access.
- MCP gives applications and tool servers a shared protocol for discovering capabilities and exchanging requests. The backend integration still needs to be built.
- The protocol includes authorization mechanisms, but your implementation still needs action-level policy, tenant isolation and appropriate approval controls.
A model that can reason but can’t reach your systems
A support assistant can read a ticket, cite the refund policy, and draft a reply a human would happily send. It can’t issue the refund. Nothing connects it to the billing system, the order record, or even the ticket it just summarized, so the one step that changes state somewhere else stays manual. The model isn’t the weak part. The wiring is.
That gap has two roots, and neither is fixed by a smarter model. A foundational model is boxed in behind whatever systems it was never given access to, and its knowledge stops at the moment training ended. Its context window, sometimes called the goldfish brain, holds only what you hand it on the current turn. The refund lives in a payments API, the order in a database, the customer’s history in a CRM, and none of them know the model exists.
Key distinction
Model quality and model usefulness are different axes. A frontier model with no connection to your systems is a very expensive autocomplete. A smaller model with clean, reliable access to the right tools can close tickets.
What this article covers
- Why a bigger context window doesn’t reach live systems, and how model-to-tool integration turns into an N×M problem.
- What MCP actually standardizes: the two-layer protocol, the host/client/server roles, and the transports.
- What tools, resources, and prompts are, and the client-side features that keep them in check.
- How MCP differs from a hand-written API wrapper and from retrieval-augmented generation (RAG).
- When MCP is worth the overhead, and the problems it hands straight back to you.
Why a larger context window doesn’t solve live system access
The obvious move is to make the short-term memory bigger. Push the window to 200,000 tokens, paste everything in, let the model sort it out. Set aside the cost of very long sequences and you still haven’t changed the thing that matters, because a bigger window changes what the model can hold, not what it can reach. It can’t run today’s inventory query or write a row. Current, authoritative data has to come from a system built to serve it, at the moment you ask.
Improving model-serving efficiency and connecting a model to business systems solve different problems. Vector stores led to retrieval-augmented generation. Proprietary function calling gave a model a way to call specific APIs, an early “phone number” that reached one capability at a time. Each solved part of the problem on its own, and each still needed a bespoke wrapper for every model-and-tool pair.
The integration code grows faster than the agent
Those bespoke wrappers are where the cost hides. Wire N models to M tools by hand and you own N×M integrations, an illustrative N×M integration problem. Three applications reaching four systems is twelve connectors; add one system and you write three more.
Every connector brings its own auth quirks, its own retry logic, its own way of turning a database row into something a model can read. Change an endpoint on the CRM and you go hunting for each connector that touched it. Meanwhile the agent logic, the part anyone actually wanted to build, sits untouched while the glue keeps growing.
Figure 1. Before a standard, every application builds its own connector to every system. Three applications and four systems already mean twelve integrations to write and maintain.
What MCP standardizes
Anthropic introduced MCP on November 25, 2024 as an open protocol. The useful idea is one agreed-on interface an agent can use to fetch information or run a task, so the shape of the connector stops being something each team reinvents.
Figure 2. A shared interface changes the shape of the problem from N×M to N+M. Read this as a reduction in protocol-facing glue, not in total work: each system still needs a server that speaks to its specific backend, but that server is written once and every compliant host reuses it.
Here’s the part worth being exact about, because plenty of write-ups blur it. MCP standardizes the wire format and the roles, not the adapter behind each system. The data layer speaks JSON-RPC 2.0 and separates requests, which expect a reply, from notifications, which don’t; the transport layer handles the channel, framing, and authorization. Keep the two layers apart and a capability behaves the same however you reach it. The protocol includes authorization mechanisms; it does not supply your organization’s action-level policies, tenant isolation or approval rules. That’s connectivity, not governance, and governance stays your job.
Host, client, server, and two transports
Three roles carry the protocol. The host is the application a person actually uses, a chat product or an AI-enabled IDE, and it owns the model. Inside it sit one or more clients, each holding a single connection to one server and translating the model’s request into MCP calls. A server runs locally or in the cloud, exposing capabilities that usually resolve to an existing enterprise API underneath. A single host can hold several clients at once and pull from several servers, with each connection independent of the others.
Where the server lives decides the transport. Stdio moves messages over standard input and output, fast for a local process, which is how a desktop app spawns a filesystem server as a subprocess. Streamable HTTP uses HTTP POST, often with server-sent events, and carries ordinary authentication such as bearer tokens and OAuth. The second one is what makes a remote, shared server workable.
Figure 3. A single tool call. The client owns one connection per server, and the host never reaches the CRM itself. Each hop has one job, which is what makes the pieces replaceable.
Tools, resources, and prompts
The MCP specification describes three server primitives. Tools are callable functions: they can read information, calculate a result or change state. Resources expose context such as file contents or database records. Prompts provide reusable interaction templates.
The primitive alone does not tell you the risk. A read-only tool can expose sensitive data; a write tool can change a customer record. Review and approval rules need to consider the actual operation and its scope.
Earlier revisions also define client features called roots, sampling and elicitation. Roots communicate intended filesystem scope; they are not a sandbox or an enforced permission boundary. Sampling requests a model completion from the host, while elicitation requests information from the user. The 2026-07-28 changelog deprecates roots and sampling for new implementations, while retaining them during the transition. Check the revision supported by your client and server before relying on a particular feature.
How MCP differs from wrapping an API yourself
You might already wrap APIs as functions and hand them to the model, which makes it fair to ask what a protocol buys you. Proprietary function calling was the precursor, and its limit was the missing open standard: every model-and-tool combination needed its own wrapper. A wrapper is a private deal between one app and one API. That’s fine for a single app hitting one or two endpoints, but it doesn’t travel. MCP makes the deal public instead. The server author settles once how the CRM is exposed, and every compliant host reads it the same way.
RAG retrieves knowledge; MCP standardizes access to tools and live systems
People line RAG and MCP up as competitors. They answer different questions and can work together. Retrieval-augmented generation retrieves relevant information and supplies it to the model. That can involve vector search, keyword search or both, and the source material can be updated rather than static. It makes the model better read.
MCP is about reaching live, structured systems. Through its primitives a model can pull context from a resource and call a tool that queries or changes a database, a CRM, or an internal API, so it covers reading as well as acting, not writes alone. RAG grounds the model in what’s written down; MCP connects it to what’s running.
Figure 4. Retrieval grounds the model in knowledge; MCP standardizes how it reaches live systems, for reading and for acting. A support agent might use RAG to recall the refund policy and MCP to look up the order and issue the refund.
An agent settling a refund usually wants both: read the policy through retrieval, then look up the order and issue the refund through MCP. Pick one and skip the other, and you get the familiar failure, an assistant that recites the policy flawlessly and can’t act on it.
Where MCP already earns its place
MCP isn’t free. You run a server, speak a protocol, and pay for tool descriptions in the context of every call. To judge whether that’s worth it, look at where it already pays off. Servers that expose Git, GitHub, and the local filesystem turn a coding assistant into something that can work against a whole repository. One enterprise request can join a CRM record, an inventory table, and a Postgres query; Amazon Q leans on an AWS Pricing MCP server to answer cost questions against live pricing. Connectors for Slack, Google Drive, and Notion handle the productivity side. Reuse is the common thread: write the server once, and many hosts consume it.
The same logic tells you when to skip it. One application calling two internal endpoints it already owns, with nobody else in line, is better off with a direct call. Promote it to an MCP server later, if a second consumer shows up.
Figure 5. Adopt MCP when connectivity is shared, exposed, or about to be reused, which is what the developer-tools, enterprise-data, and productivity use cases have in common. For a private, single-use integration, a direct call is the honest choice.
What MCP doesn’t solve
A connection standard is genuinely useful and still a narrow thing, narrower than the marketing around it suggests. The same openness that lets an agent reach any system widens the attack surface, including command injection in sloppy servers, and indirect prompt injection, where instructions buried in fetched content push an agent into misusing a tool. The protocol’s security guidance helps, but your implementation must enforce the controls.
The operational gaps are just as real. Plenty of early servers assumed a single user, so multi-tenancy, logging, and access control take real work to bolt on, and agents that run for a while drift as their retained context goes stale. That is the day-to-day of running MCP for real, and it’s the subject of the companion article. For how the governance layer covers this gap, see the Moring AI Governance hub.
What’s left after the wiring is standard
MCP provides a common protocol, and that plainness is the point: a standard only helps if it’s dull enough that everyone agrees to it. Standardizing the connection doesn’t make an agent safe or well-behaved. It takes the connection off the table as a problem, which is what frees you to spend attention on the harder questions, like which actions a model should never take without a person confirming.
If you’re deciding whether to adopt it, weigh reuse over novelty. A single app talking to an API it owns doesn’t need a protocol, but the moment a second consumer appears, the wiring you skipped becomes the thing you maintain forever, and a shared contract starts paying for itself. moring.ai works the layer above that connection, where an agent’s intent has to be reconciled with what it is actually allowed to do.
Sources and further reading
- Anthropic: Introducing the Model Context Protocol. Public launch announcement and explanation of the integration problem.
- MCP: Architecture overview. Official, maintained documentation on the host/client/server roles, transports and primitives.
- MCP: 2025-11-25 specification. Versioned technical reference for earlier implementations, including roots and sampling.
- MCP: 2026-07-28 changes. Official changes and deprecations; implementations may support different revisions.
- MCP: Security best practices. Official implementation guidance; following a protocol does not replace application-level controls.
- AWS Labs: AWS Pricing MCP Server. Public example of exposing pricing capabilities through MCP.
The integration examples and adoption criteria in this article are explanatory models, not measured results.
Frequently asked questions
What is the Model Context Protocol (MCP)?
What is the difference between MCP and RAG?
Why does a bigger context window not solve access to live systems?
How is MCP different from wrapping an API yourself?
What does MCP not solve?
Governing Autonomous AI Agents in Production
Moring provides the runtime control layer, identity verification, human-in-the-loop approvals, and audit records needed to deploy production-grade AI agents safely.
About the author
Vignesh NagarajanAI Engineer, Moring AIAtlanta
Builds AI models and benchmarks across NLP, speech and computer vision for production applications. Works on the evaluation and measurement side of agent deployments. Writes about what actually holds up when an agent meets real traffic.
LinkedIn profile