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.1 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.1 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.
Several approaches tried to work around this before MCP, and the lineage is worth knowing. Key-value cache work like Pensieve and LMCache made serving faster, but it tuned the model's own memory rather than connecting it to anything. 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.1 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, the fragmentation the source material calls the N×M problem.1 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.1
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 released the Model Context Protocol on November 25, 2024, open source from day one.2 The source material reaches for two analogies, a phone number and "USB-C for AI applications": 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.1 Adoption followed quickly, across OpenAI, Google DeepMin
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.4 Keep the two layers apart and a capability behaves the same however you reach it. What MCP does not do is decide who may call what, keep one tenant's data away from another's, or judge whether an action needs a human's sign-off. That's connectivity, not governance, and governance stays your job.
Host, client, server, and two transports
Three roles carry the protocol.4 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.4 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
A server exposes three kinds of thing, and the differences carry weight.4 Tools are functions the model can call to change something on the far side, such as writing a file, updating a record, or running a query that mutates data. Resources are read-only context, handing back file contents or database rows without doing anything. Prompts are reusable templates, a system prompt or a worked example, that shape how the model works with a server.
The split between tools and resources is the one to hold onto. It draws the line between reading the world and changing it, which is exactly where your review and approval logic belongs. A bad resource read shows the model stale data. A bad tool call moves money.
A second set of features handles safety, and the spec puts them on the client, offered back to the server instead of exposed by it.4 Roots limit a server to specific resources, so it can only touch what you've allowed. Sampling lets a server ask the host for a model completion partway through a job. Elicitation lets a server ask the user for more input mid-task, with the user still in control. Servers provide capability; clients hold the guardrails.
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.1 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 aren't; they answer different questions, and the source material treats them as complementary.5 Retrieval-augmented generation turns documents into embeddings and drops the relevant passages into the prompt, so the model can answer from static material it was never trained on, like manuals, policies, or old tickets. 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.5 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.6 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, and the source material is direct about it: command injection in sloppy servers, and indirect prompt injection, where instructions buried in fetched content push an agent into misusing a tool.7 The protocol defends against neither. You do.
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.7 That is the day-to-day of running MCP for real, and it's the subject of the companion article.
What's left after the wiring is standard
MCP is a wire format and a few roles, 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
- "The Model Context Protocol (MCP): Emergence, Technical Architecture, and the Future of Agentic AI Infrastructure" (supplied source), §I and §III.A: foundational-model constraints, the goldfish-brain context window, context-window economics, KV-cache work (Pensieve, LMCache), the N×M problem, and proprietary function calling as MCP's precursor. ↩
- Anthropic, "Introducing the Model Context Protocol," November 25, 2024. anthropic.com/news/model-context-protocol. ↩
- Emergence document (supplied source), §I.B: adoption by OpenAI, Google DeepMind, Microsoft (Copilot Studio), and AWS (Amazon Bedrock). Dates verified separately: OpenAI Mar 26, 2025; Google Apr 9, 2025. ↩
- Emergence document (supplied source), §II.A–C: host/client/server roles, the data/transport layers, JSON-RPC 2.0, stdio and Streamable HTTP transports, and the primitives. Client-side placement of Roots, Sampling, and Elicitation confirmed against the MCP spec: modelcontextprotocol.io/docs/learn/architecture. ↩
- Emergence document (supplied source), §III.B, Table 2: RAG as knowledge grounding versus MCP as standardized access to tools and live systems; the two are complementary. ↩
- Emergence document (supplied source), §VI.B: use-case clusters, including developer tools (Git, GitHub, filesystem), enterprise data (Amazon Q with an AWS Pricing MCP server), and productivity connectors (Slack, Google Drive, Notion). ↩
- Emergence document (supplied source), §V and §VI.C: expanded attack surface (command injection, indirect prompt injection), single-user origins, and context drift. Covered in depth in the companion article. ↩
Editorial note: statements about what MCP standardizes and what it leaves unsolved are Moring.ai's interpretation. Protocol behavior, examples, and figures are drawn from the supplied source documents, with the announcement date and the client/server placement of Roots, Sampling, and Elicitation cross-checked against Anthropic and the MCP specification. The current MCP specification revision is 2025-11-25.
