Are MCPs Overhyped? A Rant about MCPs

In November 2024, Henry Mao went down a rabbit hole trying to tackle ARC-AGI. The task looks straightforward: given two or three examples of a grid transformation, infer the rule and complete a missing output. Mao, the founder and CEO of Smithery, an MCP steering committee member, and previously a cofounder of Jenni AI, began with a problem that seemed to expose the gap between human reasoning and language models. He describes human accuracy as about 80%, an approximate baseline whose task split he does not specify.

Then OpenAI’s o3 changed the picture. Mao describes its ARC-AGI-1 performance as human-level and points to strong math results as well. The historical breakthrough concerned the December 2024 o3 preview, rather than the later released model; its results depended on the compute configuration. The apparent conclusion—AGI achieved, autonomous agents ready to solve everything—is deliberately ironic. By 2025, the obvious question was still: where were the agents doing the tasks people did not want to do? Frontier intelligence remained stuck in a box.

Making an agent useful requires attention to context and capability: what information can enter the model, and what actions can leave it? Intelligence alone does not supply access to a repository, a ticket tracker, or the operations those services expose. Those inputs and outputs need an integration layer.

Anthropic introduced the Model Context Protocol in November 2024 to standardize those connections. Without a shared protocol, each model application needs its own integration with each service—the N-times-N problem Mao describes. MCP gives applications and services a common way to communicate, reducing the need to rebuild each pairing independently.

Smarter models, standardized service communication, and a small but vibrant developer community made this an appealing foundation. Yet a common protocol leaves an ecosystem to build. Once services begin targeting agents, discovery, installation, operations, and commercial relationships become problems in their own right.

As more MCP servers appear, finding a high-quality one becomes harder. At the time of the talk, the MCP committee was working on an official registry, with Mao crediting the PulseMCP team. A registry provides somewhere to look; it does not settle how to assign reputation or distinguish a dependable server from a poor one.

The remaining user problems follow the path from discovery to actual use:

• Installation: Mao describes GitHub repositories that require a five-step setup process. Each step adds friction before the agent gains any capability.
• Security: Completing installation does not establish that the installed server is secure.
• Payments: An agent needs a way to pay for services on its user’s behalf. Mao’s illustrative concern is having to subscribe to 100 separate services at $10 per month each. The ecosystem needs a workable purchasing experience as well as a connection protocol.

Streamable HTTP makes more hosting platforms available to MCP developers, but it does not remove runtime design decisions. Stateful sessions and resumability can still require operational work. In the March 2025 transport specification, session IDs and resumability are optional: the challenge applies when a server uses those capabilities, rather than being a requirement that every server maintain resumable state.

The official MCP Inspector supplies a basic way to test tools and inspect prompts. That helps a developer examine the interface, but Mao’s next questions concern what happens when an agent encounters it: how should the server be designed, will the model call its tools, and what produces the best agent experience? A tool can be available and testable while its usefulness to an agent remains an open design question.

Publishing a server introduces another set of developer needs:

These concerns connect to the user problems without being identical to them. Users need to find and pay for useful capabilities; developers need a route to those users and enough visibility to improve what they provide.

Mao says he started Smithery around December 2024 to address both sides. Its ambition is to become an AI gateway that grows and orchestrates services built for agents. That is a broader role than listing servers: it encompasses the path between a developer publishing a capability and an agent successfully using it. Mao acknowledges that Smithery has only scratched the surface of the problems he has identified.

The Smithery playground demonstrates what becomes possible when some of those connection problems are handled. Mao presents it as giving an agent access to thousands of curated MCP servers. His request is to find the most pressing issue in smithery-ai/cli and create a new ticket in Linear. The repository name here is the one used in the recording; its public link now redirects to arcadeai-labs/smithery-cli.

The visible workflow crosses both discovery and execution:

1. Search for servers. After the prompt is submitted, the agent thinks through the task and invokes a search-servers function to look through Smithery’s catalog.
2. Connect to services. It connects to a selected server and to Linear.
3. Read GitHub issues. Through the GitHub MCP, it retrieves bugs and looks for the highest-priority item.
4. Create the destination ticket. It finds a Linear team and then creates a ticket.

The playground reports that the ticket was created. Its confirmation shows SMI-374, a connection-error title, priority High (2), the Smithery team, and a Linear link. This is the transition from a requested action to a reported result: the agent has read from GitHub and written to Linear.

Mao then opens the ticket and points out its detailed content and a link back to the original GitHub issue. The demonstration completes a task across two MCP connections, preserving a route from the new work item to its source. It does not independently establish that the chosen issue was the repository’s most pressing problem; that prioritization remains the agent’s judgment within the demonstration.

The demo is deliberately narrow, but a growing set of services expands the tasks agents might complete. Mao closes by pointing to deployment and tool-call growth over the preceding months. The displayed tool-call chart carries the headline “90K+ Tool Calls / Day.” That adoption evidence, together with developer enthusiasm, grounds his confidence that the ecosystem can address the remaining problems.

His larger forecast is an internet dominated by tool calls rather than clicks, where agent experience matters more than user experience. In that world, the practical interface to a service includes whether an agent can discover it, understand when to use it, connect successfully, and complete a useful action. Building that experience will require the broader developer community—not just Smithery or a handful of companies.