The MCP Folly: More Context Isn't Always Better

2 Sents

I keep watching teams wire every Slack channel and Jira board into an agent through MCP, then wonder why it hallucinates. MCP is useful when you need a gated, repeatable bridge to one system. Dumping your whole toolchain into context is the same mistake as context poisoning, with extra JSON.

Illustration of an AI agent overwhelmed by data icons representing context pollution

I fell for this myself. I connected more MCP servers because the Model Context Protocol made it easy, and Anthropic obviously wants you to use a protocol they invented. The agent got slower and dumber. Not because MCP is broken. Because I was feeding it everything instead of the two files and the log line that actually mattered.

What MCP is (when you need the primer)

MCP is an open standard for hooking tools and data into an agent without writing a new integration every time. In practice you get three kinds of hooks:

Resources — read-only stuff the model can pull in (docs, schemas, file trees).
Prompts — saved templates for recurring tasks.
Tools — things the model can run (create a file, hit an API, kick a build).

That's the whole pitch. Less glue code. Fine. The failure mode is treating "less glue code" as "plug in everything."

The mistake I keep seeing

Someone asks Claude to fix a checkout bug. The agent already has the repo indexed. Then the session also loads last week's Slack thread, open Jira epics, and three MCP resources nobody curated. The model spends tokens on noise and still misses line 45 in CheckoutController.ts.

I wrote about the same mechanic under a different name in context poisoning. MCP is just a sanctioned way to poison yourself faster.

When I still reach for MCP

MCP earns its keep in narrow cases:

Locked-down environments where you need an audited gate between the model and internal data.
Weird internal tools with syntax the model will invent if you don't give it a translator server.
Multi-step flows where you want the agent on a fixed, reviewable path instead of improvising curl.

For day-to-day coding I mostly want a lean @ on the files I'm editing, maybe a doc link, and a pasted stack trace. I use Vercel's MCP when I need deployment context. I don't need my entire SaaS stack in the prompt to rename a React component.

Where this goes

Models will get better at reaching into systems without us hand-building every bridge. MCP feels like that bridge era: useful now, not the forever architecture. I'd rather learn the habit of small context now than unwind a "connect all the things" setup in a year.

If your agent feels lost, try disconnecting half your MCP servers before you blame the model. Nine times out of ten the fix is boring. Fewer inputs, sharper ask, same human on the other side of the keyboard.

What MCP is (when you need the primer)

MCP is an open standard for hooking tools and data into an agent without writing a new integration every time. In practice you get three kinds of hooks:

Resources — read-only stuff the model can pull in (docs, schemas, file trees).

Prompts — saved templates for recurring tasks.

Tools — things the model can run (create a file, hit an API, kick a build).

That's the whole pitch. Less glue code. Fine. The failure mode is treating "less glue code" as "plug in everything."

The mistake I keep seeing

I wrote about the same mechanic under a different name in context poisoning. MCP is just a sanctioned way to poison yourself faster.

When I still reach for MCP

MCP earns its keep in narrow cases:

Locked-down environments where you need an audited gate between the model and internal data.

Weird internal tools with syntax the model will invent if you don't give it a translator server.

Multi-step flows where you want the agent on a fixed, reviewable path instead of improvising curl.

Where this goes