Anthropic’s developer account ClaudeDevs shared a new blog post this week focused on “Building agents that reach production systems with MCP,” pitching a more structured approach to tool access as AI agents move from demos into production work.
In the post, ClaudeDevs positions the decision as a pragmatic one: when to use direct APIs, when CLIs are the better fit, and when MCP is worth the added layer. The blog also calls out patterns for building MCP servers, designing context-efficient clients, and pairing MCP with “skills.”
The practical question: direct APIs vs CLIs vs MCP
The reaction thread quickly turned into a field guide of its own, with developers debating where each approach holds up best.
Some argued for staying closer to the metal. One reply suggested skipping MCP “unless wrapping legacy CLIs,” claiming direct APIs still win on “latency and reliability.” Another noted that a native package can be preferable to an MCP wrapper in some cases, citing Playwright as an example of where an npm bundle can offer “easier tool calls” and more functionality.
Others described MCP as paying off once tool use becomes multi-step or cross-system. One developer shared a rule of thumb: MCP tends to win when an agent maintains context across “3+ invocations,” while direct API calls remain faster for one-shot operations—resulting in a hybrid setup where knowledge retrieval moved to MCP and stateless tools stayed as direct calls. Another reply summarized the tradeoff as “blast radius,” arguing that direct APIs can fail with errors that are easier for on-call engineers to diagnose, while MCP “earns its keep” when an agent needs to hop across multiple systems without repeated authentication overhead.
Context efficiency and “group by intent, not endpoints”
A recurring theme in replies was context overhead—both in tool definition bloat and repeated discovery calls.
Multiple developers highlighted the blog’s advice to “group tools around intent not endpoints.” One reply criticized the common tendency to mirror an OpenAPI spec, then “wonder why agents stumble on 40 primitives,” pointing to a Cloudflare example mentioned in the thread: “2 tools, 2500 endpoints, ~1k tokens.”
Another developer claimed large savings from this style of approach, saying MCP servers for voice agents reduced per-call context from “15k” tokens to “under 4k” by letting the agent pull only what it needs.
Skills, server-shipped capabilities, and admin control
The thread also surfaced where builders want MCP to go next.
One developer called out the “deliver skills directly from servers” extension as urgent, arguing that “versioned, server-shipped skills are the right primitive,” and describing today’s plugin approach as a preview of what a protocol extension could enable.
Separately, governance and oversight came up as soon as talk shifted from tool access to production systems. One reply argued “admins need more control and visibility” than MCP servers alone provide, describing work on a policy layer to evaluate each action an agent takes against production systems. Another summed it up more bluntly: “MCP is becoming the pipe, control is more like the product.”
Ecosystem pressure: what’s missing
Developers also used the thread to ask for specific integrations, including a request for Firebase connectivity “like” an existing Supabase connection, and a call for an “official Azure SQL MCP.”
One commenter read the timing as a response to criticism elsewhere, saying Perplexity had cited “context overhead and auth friction” as reasons for moving away from MCP toward direct APIs, and that this blog arrives shortly after addressing those objections.