Why Narrowing MCP’s Role Makes Sense for Select Agent Use Cases

‍

By Dickey Singh, CEO and Founder, Cast.app

For several production use cases, direct APIs, direct DB access, and context and content injection gave us better control with less latency, fewer tokens, and less context waste than loading large tool surfaces upfront.

We were early on MCP. We even extended MCP with Cast MCP Proxy Server to connect with legacy CRMs and Customer Success Platforms.

We wrote about it in Your First CX MCP Server and later in The Agentic RAG Ladder because MCP was useful for helping the market think more clearly about how agents connect to real systems.

But over time, we narrowed its role.

Not because MCP is bad.
Not because it never worked.
It did.

But for select agent use cases, it stopped making sense.

The issue was not integration itself.
The issue was overhead.

The more tool definitions, descriptions, schemas, and wrappers you load into the model upfront, the more you pay somewhere else: latency, tokens, context, and control.

The model’s context window is too valuable to fill with integration detail it may never need.

Anthropic has since introduced Tool Search and Programmatic Tool Calling specifically to reduce context-window pressure and the cost of conventional tool-use patterns.

Dropbox described a similar lesson in Dash: as tools increased, definitions consumed context, and longer-running jobs got worse because tool calls were adding too much extra context.

The model’s context window is too valuable to fill with integration detail it may never need.

At Cast, for several production use cases, direct API access, direct database access, and context and content injection worked better.

That approach lets us bring in only the data we need, when we need it, instead of loading a large integration surface and hoping the model picks perfectly from it. It gives us tighter control over what actually enters context, and more control over transformation, ranking, security, reliability, and handoffs.

It also opens the door to a more flexible integration pattern.

When docs or specs are available, agents can increasingly read the documentation, understand the shape of the system, and generate or adapt integrations more directly instead of being boxed in by prebuilt wrappers.

That is close to the direction David Zhang described publicly when he said Duet removed MCP integrations in v2 after starting with full MCP support.
Anthropic’s programmatic tool-calling approach and Cloudflare’s Code Mode both point in a similar direction: move more orchestration into code, reduce unnecessary context, and let the system pull in only what it needs.
Cloudflare is one of the clearest public examples. Rather than expose a huge API as a growing catalog of fixed tools, it compressed Cloudflare API access into two tools with a small, fixed context footprint, and explicitly framed that as a response to the token and maintenance cost of large MCP tool surfaces.
OpenClaw is another useful signal. Its ecosystem does support MCP, but through mcporter rather than first-class MCP runtime in core. OpenClaw’s own vision doc says this keeps the core tool and context surface lean and reduces churn and security impact, while mcporter itself can package MCP servers as CLI tools.

That is not identical to what we do at Cast, but it points in the same direction: narrower control layers, less upfront tool surface, and more selective exposure.

This is also why we do not see this as an anti-MCP story.

MCP still makes sense in some scenarios: quick bootstrapping, standard tool exposure, simpler integration surfaces, and cases where interoperability matters more than absolute performance and control. LangChain made a similar distinction publicly: MCP is often more useful when bringing tools to an agent you do not control than when you are building a tightly controlled agent for a specific task.

So this is not “MCP is dead.”

It is simpler than that.

For select agent use cases, especially the ones that care about latency, token efficiency, context discipline, tighter behavior control, large API surfaces, or richer agentic workflows, MCP often stops being the default architecture we would choose first.