Claude blog outlines how agents should use MCP, APIs, and CLIs

Claude blog outlines how agents should use MCP, APIs, and CLIs

Claude released a blog post titled "Building agents that reach production systems with MCP" that walks through when an AI agent should call a direct API, invoke a CLI, or route through the Model‑Centric Programming (MCP) layer, and it also provides server and client patterns. The post is available on the Claude blog and was announced via a tweet from @ClaudeDevs.

Choosing the right interface

The article breaks the decision space into three buckets. Direct APIs give the lowest latency and full type safety, but they require the agent to know the exact contract. CLIs are useful when the target system only exposes a command‑line wrapper or when a quick‑and‑dirty integration is acceptable. MCP sits in the middle: it abstracts the call behind a model‑driven schema, letting the agent reason about inputs and outputs without hard‑coding endpoints. For most startup services, the author suggests starting with APIs for core data paths and falling back to MCP for exploratory or user‑facing actions.

Server and client patterns

MCP servers are presented as thin adapters that translate model calls into concrete service requests. The blog recommends a stateless, request‑scoped design to keep scaling simple. On the client side, a "context‑efficient" wrapper caches schema look‑ups and reuses model embeddings, cutting round‑trip overhead by up to 30% in the author's benchmarks. The patterns are language‑agnostic, but the examples use Python for clarity.

Pairing MCP with skills

MCP can be combined with modular "skills" – reusable functions that encapsulate domain knowledge. By registering a skill with the MCP server, an agent can invoke high‑level behaviors (e.g., "schedule a meeting") without re‑implementing the underlying workflow each time. This decouples business logic from the agent's prompting strategy and makes testing more straightforward.

Caveats and when to skip MCP

While MCP reduces boilerplate, it adds an extra network hop and a runtime dependency on the MCP server. Early adopters have reported occasional schema mismatches that surface as false‑positive errors, especially when services evolve faster than the model schema. For latency‑critical paths or very small teams, the added complexity may outweigh the benefits. Treat MCP as an optional layer rather than a default.

What to watch – If you already have stable APIs, prototype an MCP wrapper for a single low‑traffic endpoint and measure latency and error rates. The results will tell you whether the abstraction overhead is acceptable for your product roadmap.