Key Summary
- As MCP (Model Context Protocol) servers each expose dozens of tools and schemas, the agent’s context window is becoming bloated.
- Critiques argue that in today’s agent environments, where code execution and direct API calls have matured, most MCP servers are no longer essential.
- As an alternative, the proposal is to replace MCP servers with HTTP APIs and CLIs that already offer standard interfaces.
This analysis argues that MCP, which had established itself as the de facto standard for tool calling in the AI agent ecosystem, must reassess its utility as code execution and direct API call capabilities continue to grow.
Table of Contents
- Key Summary
- First Critique of MCP: Context Bloat
- Second Pillar of MCP Critiques: Direct Calls Become Realistic
- Alternative: Switch Tool Exposure to HTTP APIs and CLIs
- A Balanced View After MCP Critiques: Where MCP Still Holds Value
- Practical Choices After the MCP Critiques
- Practical Application Points
- What to Try Right Now
- Frequently Asked Questions
- Reference Source
In September 2026, StepFun’s released Step 5 Preview was recorded as orchestrating roughly 950 web fetches in a single agent action. It features a 600B-parameter sparse MoE architecture with a deep and narrow design of 92 Transformer layers. What this case implies is more than a simple performance number. It marks a leap in the agent’s ability to handle tools and APIs directly. Against this backdrop, MCP critiques of MCP (Model Context Protocol)—long hailed as the standard for agent tool integration—have resurfaced.
First Critique of MCP: Context Bloat
The first issue at the center of MCP critiques is context bloat. A single MCP server defines dozens of tools and their corresponding schemas, and the agent must include them in the system prompt every time. As the number of servers grows, the context window swells exponentially, and token costs and response latency rise together.
The losses felt in practice are more direct. When a model is in a state where there are “too many tools available,” the rate at which it selects the wrong tool increases, which in turn leads to retries and cost spikes. The author considers this the most substantive problem. Under the banner of “standardization,” each MCP server has emerged with its own schema, and as a result, agent developers are spending more time on context management than on actual integration work.
Second Pillar of MCP Critiques: Direct Calls Become Realistic
The second critique is more fundamental. As code execution and direct API call capabilities have grown, the argument is that the MCP intermediary layer has itself become a bottleneck. Today’s agents can spin up a shell, hit an HTTP API with a single curl call, process the response with jq, and pass the result to the next step. The Step 5 Preview’s 950 web fetches show that this direct-call pattern has become viable even at large workload scales. This is why the view that MCP’s promised “standard for tool calling” was, in fact, just one more wrapper around standard-interface HTTP API and CLI calls is gaining traction.
Alternative: Switch Tool Exposure to HTTP APIs and CLIs
The alternative proposed by MCP critics is surprisingly plain. Expose tools as HTTP APIs and CLIs, and let the agent call them directly through code execution. Authentication is handled via OAuth/API keys, and tool definitions are only loaded into context as function signatures when needed. This approach dramatically reduces context footprint while allowing tools to evolve freely without being tied to MCP spec changes.
| Item | MCP Server | Direct HTTP API Call | Direct CLI Call |
|---|---|---|---|
| Context cost | High (tools/schemas loaded at all times) | Low (defined only when needed) | Low (shell call) |
| Standardization level | Dependent on MCP spec | Mature standards such as OpenAPI | POSIX/shell conventions |
| Multi-step workflow | Strength | Moderate (direct implementation) | Moderate (direct implementation) |
| Authentication | Handled internally by MCP | OAuth/API key | Environment variables/key files |
| Maintenance | Requires server update propagation | Independent per endpoint | Independent per binary |
As the table shows, MCP’s strength lies in “exposing multiple tools as a single bundle.” However, the core of the critique is that its standardization advantage is not large enough to justify that cost.
A Balanced View After MCP Critiques: Where MCP Still Holds Value
The claim that MCP is useless is premature. When you need to bundle and expose a non-standardized internal system to an agent in one go, MCP’s tool bundling is still valid. However, for workloads that are dominated by common SaaS APIs, CLIs, and web calls, it pays to skip MCP altogether. Ultimately, the answer is not a single solution but a workload-specific mix.
Practical Choices After the MCP Critiques
As of September 2026, agent tool integration has moved past the stage of “unifying the answer with a single protocol.” Choices diverge depending on who bears the context cost of tool definitions, how much standardization is required, and who manages authentication and authorization. The significance of MCP critiques is that they have reopened this choice.
Practical Application Points
- For MCP servers exposing more than five tools, consider switching to direct HTTP API calls first.
- Monitor context cost: measure the input token share taken up by tool definitions on a weekly basis.
- If the workflow ends in just one or two simple call steps, it is better to skip MCP’s intermediary layer.
- Adopt a hybrid strategy as the default: bundle legacy internal systems with MCP, and separate external SaaS into direct calls.
What to Try Right Now
- Extract tool definitions from your currently running MCP server and measure the tokens consumed in context.
- Redefine the same functionality as an HTTP API with an OpenAPI spec, and write code that lets the agent call it directly from the shell.
- Simplify the authentication flow to OAuth/API keys, and reduce dependency on MCP-internal authentication.
- Verify in logs whether context cost grows linearly as the number of tools increases.
- Bundle only legacy systems lacking internal standards with MCP, and separate the rest into direct calls.
Frequently Asked Questions
Should I tear out MCP right away?
No. MCP is still efficient when you need to bundle multiple internal legacy tools at once. For new integrations, it is reasonable to start with an HTTP API/CLI foundation.
How much does context bloat actually affect cost?
If tool definitions are sent with every request, cases have been reported where 20–40% of input tokens are consumed by tool metadata. Depending on the model and pricing plan, the difference can amount to several million won per month.
What are the drawbacks of direct HTTP API calls?
The agent must handle authentication, retries, and error handling itself. As multi-step workflows grow longer, code complexity rises quickly, so this approach is most effective when tool count is small and call frequency is high.
Why are the 950 web fetches in Step 5 Preview important?
Because they are evidence that an agent can reliably orchestrate large-scale tool calls without human intervention. Once this capability becomes widespread, the bottleneck in tool integration will shift from “which protocol” to “which code to write.”
Reference Source
This article was written after reviewing the following source: geeknews — Was MCP a flawed idea from the start?
Expert Commentary (AI)
ML Systems Engineer
The critique of MCP’s context bloat is a measurable real-world problem, but “replacing it with code execution” hides an overreliance on model capabilities
The structural bottleneck observed in real agent operations—where tool definitions occupy the system prompt at all times, raising both input token costs and tool-selection error rates—is genuine. The motivation to save context is valid, and approaches such as dynamically loading tool definitions only when needed or condensing them to function-signature level can yield immediate practical improvements when combined with prompt caching and RAG-based tool retrieval. However, direct calls based on code execution rest on the premise that the model has sufficient planning and error-recovery capabilities. With smaller models or low-cost deployment environments, MCP’s schema enforcement actually serves as a guardrail that lowers error rates. In addition, direct-call approaches push authentication, retry logic, and sandbox isolation entirely onto the agent code, so in multi-step workloads beyond a simple one- or two-step call, maintenance costs can actually flip. In the long run, the question is less about whether the protocol survives, and more about how the standards-level specification can standardize “delayed loading and progressive discovery” of tool definitions.
API Platform Architect
The proposal to return to mature HTTP APIs and CLIs as tool interfaces is practical, but it leaves MCP’s interoperability and permission delegation problems for each organization to solve
Layering agents on top of already-validated interfaces such as OpenAPI and POSIX-family conventions is a sound idea that reduces the waste of reinvention. From the tool provider’s perspective as well, there is no need to operate a separate MCP server, and agent accessibility can be secured with nothing more than the existing level of API documentation, which lowers the barrier to ecosystem entry. However, the core value MCP sought to standardize—a consistent model for tool discovery, session management, and delegated permission (scope-based authentication)—must be reimplemented per service under the direct-call approach, and in real workloads where an agent hops across dozens of SaaS products, this can cause integration costs to surge again. From a security standpoint, giving the agent shell and broad network access means the attack surface in the event of a prompt injection is far wider than MCP’s sandbox. In the end, this alternative is most likely to settle as a workload-specific mix of “MCP for legacy integrations, direct calls for mature APIs,” and it is more accurate to read this not as the fall of a single standard, but as a contraction of the standard’s role.
Critical Analyst
The timing itself is suspicious — the MCP backlash reads like an infrastructure power struggle disguised as a technical debate
The official narrative is a clean evolutionist story: “technology has advanced, so the intermediary layer is no longer needed.” But the picture changes when you look beneath the surface. MCP was born from a specific model provider’s ecosystem expansion strategy, and the structure in which the model vendor’s own client controls the context window gives the platform business enormous leverage. The critique that tool definitions occupy context is factually true, but it is interesting that the stakeholders charging the cost as “token billing” and the stakeholders selling code-execution sandboxes as the solution overlap. When large API providers push “call us directly through code execution,” the entry point of the tool ecosystem can shift from an open protocol to their own infrastructure. In other words, this debate is less about MCP’s survival and more about who owns the gateway through which agents access tools. What readers should ask themselves is: why does the side emphasizing “token cost of tool definitions” argue for a full architectural overhaul instead of inexpensive solutions like context caching, who benefits from that alternative, and why now.
Underlying Scenarios
- The “context bloat” framing is in fact a long-standing issue, but it appears to have been reignited by piggybacking on flashy new-model launch demos such as “950 web fetches” — the timing conveniently aligns with the interests of the new-model vendor seeking demo buzz and the platform business that wants to weaken protocol lock-in and drive more direct use of its own API.
- The more pressure there is to dismantle MCP, the more room there is for the MCP camp to re-arm with “official code execution runtimes” or “paid dynamic tool loading features,” and the critical debate itself may function as a market-shaping mechanism that creates demand for paid upgrades.
Leave a Reply