The “C” in MCP: Why Context Is the Hardest Part of Enterprise AI

The agent didn’t give a wrong answer because the model was weak. It gave a wrong answer because the data it received carried no meaning.

Over the past year, the Model Context Protocol (MCP) has done something genuinely useful: it standardized how an AI agent connects to the systems it needs. One protocol, one way to discover tools, one way to call them. The M and the P, the model and the protocol, are largely solved.

The C is not. And the C is the whole point. Context is what tells an agent what a number actually means, which table to trust, and which definition of “revenue” the business stands behind. MCP gives an agent a clean way to reach your data. It does almost nothing to tell the agent what that data means.

First, what “context” even means for an agent

A language model ships knowing nothing about your business. It has never seen your schemas, your fiscal calendar, or your definition of an active customer. Everything it knows about your situation has to be placed in front of it at the moment it answers. That working set of information is its context.

Anthropic, which created MCP, defines it plainly: context is “the set of tokens included when sampling from a large language model”, the instructions, the tools, the data pulled in over MCP, and the conversation so far. Getting an agent to behave is less about clever prompting and more about curating that set so the model has exactly what it needs, and little else.

Two things make this hard. First, context is finite. A model has an attention budget, and the more tokens you cram in, the less reliably it uses any of them, a documented failure mode researchers call context rot. Second, context is where meaning lives. The model can reason beautifully over what you give it, but if what you give it is ambiguous or unexplained, it will reason its way, with total confidence, to the wrong answer.

So the question that decides whether an enterprise agent works is not “how smart is the model.” It is “how good is the context the model receives.” Here is what that difference looks like on a single row of data. Flip the toggle:

What MCP gives you, and what it leaves out

An MCP tool call is a connection, not an explanation. When an agent calls a tool that wraps a database or an API, what comes back is rows and columns, exactly as stored. The protocol carries the values. It does not carry the years of tribal knowledge a human analyst uses to read those values correctly.

That gap is not a detail. Analyses of enterprise MCP are blunt about it: without governance and semantic grounding, servers that expose raw database access let agents hallucinate on unfamiliar schemas, producing confident, inconsistent, untrustworthy results. The tool worked. The plumbing worked. The answer was still wrong.

The same row, two very different readings

Here is a single record from a customer table, the way an MCP tool hands it to an agent, next to what anyone on your data team already knows about it.

A person reads around all of this without noticing. An agent cannot, because none of it is written in the data itself. It is the same wall the research community keeps hitting: the BIRD benchmark was built from real, messy enterprise databases whose columns carry terse, coded names that are impossible to interpret without outside documentation, and the scores show exactly how much that documentation is worth.

Three ways missing context breaks an agent

Each of these is a real failure mode, and in each one the SQL is valid and the tool call succeeds. Step through them:

Why you can’t fix this in the prompt

The instinct is to paste the data dictionary into the system prompt and move on. It doesn’t scale, for two reasons.

Volume. Enterprise schemas carry thousands of columns, and the knowledge that explains them is scattered across wikis, tickets, and chat threads measured in millions of tokens. You can’t fit that in every request, keep it current, or enforce who is allowed to see what. And even if you could, you’d pay the context-rot tax on every call: the more you dump in, the less reliably the model uses any of it.

Authority. Ask for “active customers in EMEA last quarter” and the agent needs the certified definition of active, the approved join logic, the right fiscal calendar, and the correct access rules. Finance and sales each have a real, different definition of “revenue.” Without something that says which one the business stands behind, an agent can pull a real number and still be wrong. Meaning has to be attached to the data before the question is ever asked, not improvised at inference time.

Ground the data before the agent sees it

The fix is to attach meaning at the source, so every tool call returns data that already carries it: the canonical schema, representative samples, the units and encodings, the relationships, the lineage that says which table is trustworthy, and the policies that say who may see it. Grounding happens once, and every agent inherits it.

At Nexla, that layer is Helix, a per-enterprise knowledge graph and vector database that ingests your schemas, documents, metadata, lineage, and prior agent runs, then feeds that grounding into every MCP tool call before data reaches the agent. It pairs with a second idea the research backs up: task-shaped MCP servers that carry only the handful of grounded tools a workflow needs, rather than one giant catalog. Fewer tools to misread means higher tool-selection accuracy and less for the agent to get wrong. Connection and context pull in the same direction.