MCP exists because APIs assume the caller read the docs

Automation Engineering · By Caleb Sakala · April 11, 2026

A fintech team connected their AI agent to Stripe’s API last month. Stripe exposes over 300 endpoints. The agent needed to process a customer payment. It chose POST /v1/charges.

That endpoint works. It processes payments. It also skips 3D Secure verification, doesn't create a PaymentIntent object for tracking, and has been soft-deprecated since 2019. The customer's bank flagged the transaction. The compliance team spent a week untangling it.

The agent made a technically valid API call to a technically wrong endpoint, because nobody told it that /v1/charges exists mainly for backward compatibility. That context lives in Stripe's migration guide, paragraph four, under a yellow warning banner. An LLM scanning an OpenAPI spec will never find it there.

APIs assume the caller read the docs. AI agents don't read docs. They receive schemas and pick the endpoint that pattern-matches closest to the task description.

That mismatch is the entire reason Model Context Protocol exists.

300 endpoints and an agent that picks the wrong one

Traditional APIs were designed for developers who understand the domain. A payments developer knows to use PaymentIntents. A shipping developer knows the difference between POST /shipments and POST /labels. The documentation fills gaps in knowledge, and the developer's judgment handles the rest.

AI agents have no judgment about API design conventions. Hand an LLM the Stripe OpenAPI spec and ask it to process a payment. It will scan parameter names, match them against the task description, and select whichever endpoint has the closest semantic overlap with the prompt. Sometimes it picks correctly. Sometimes it picks a deprecated endpoint that still returns 200 OK.

This problem scales with API surface area. A small integration with 5 endpoints is manageable. An enterprise service with 75-100 endpoints introduces what Auth0's engineering team calls the "paradox of choice": more options make the agent less accurate. Internal testing at multiple AI labs has shown that agent tool-selection accuracy drops measurably once the option count exceeds roughly 15-20. Past 50, accuracy degrades to the point where manual intervention becomes the norm rather than the exception.

The standard workaround is manual curation. A developer writes wrapper functions that expose only the endpoints the agent needs, with descriptions tuned for LLM comprehension. This works until the underlying API changes and the wrapper breaks. Every team building agent integrations in 2025 and 2026 has rebuilt this glue code from scratch, for every service they connect to.

MCP gives agents a toolbox instead of an encyclopedia

Model Context Protocol standardizes the pattern that teams were already building manually. Instead of handing an agent an entire API specification, an MCP server exposes a curated set of tools, each with a name, description, and typed parameter schema.

The same Stripe scenario through MCP: instead of 300 endpoints, the agent connects to a Stripe MCP server that offers five tools. process_payment handles the PaymentIntent flow internally. refund_payment wraps the refund logic. get_customer retrieves customer records. The agent picks from five options with clear descriptions rather than parsing thousands of lines of YAML.

The runtime handshake is what separates this from a static wrapper library. When an agent connects to an MCP server, it requests the full list of available tools. The server responds with names, descriptions, and input schemas in a structured format. The agent knows exactly what it can do before it attempts anything.

This dynamic capability means tools can change on the server side without redeploying the agent. A new feature appears in the tool list the next time the agent connects. The agent adapts because the protocol supports live registration. Compare that to a hard-coded API wrapper that requires a code change, a pull request, and a deploy cycle every time the upstream service adds a new capability.

Every MCP server is still making API calls under the hood

Most "MCP vs API" explanations frame these as competing approaches. The architecture tells a different story.

When an agent calls the process_payment tool on a Stripe MCP server, the server itself makes a REST call to POST /v1/payment_intents with the correct headers, authentication, and parameters. The REST endpoint hasn't gone anywhere. The MCP server translates a high-level tool invocation into the specific calls that accomplish it.

The stack looks like this: Agent → MCP Protocol (JSON-RPC) → MCP Server → REST/GraphQL → Service. Three hops where there used to be one. The MCP server is the new layer. It holds the domain knowledge that the agent lacks: which endpoint to call, what parameters to set, which deprecated paths to avoid.

This layering has real infrastructure cost. Each MCP server is a running process (for local stdio transport) or a remote HTTP endpoint (for the newer Streamable HTTP transport). For local connections, that means one process per active server. For remote connections, that means an OAuth 2.1 authorization flow and a hosted service that must remain available. Ten server connections means ten processes, ten auth configurations, and ten potential failure points in the workflow chain.

Whether that curated interface justifies the infrastructure depends on what the agent is doing with it. A workflow step that calls one known endpoint once per day does not need runtime tool registration. A step where the agent searches a knowledge base, selects from available data sources, and synthesizes results across them does.

Where MCP creates problems it was supposed to solve

MCP's value proposition is simplification. But several deployment patterns introduce complexity that the protocol doesn't yet handle well.

Server sprawl. A team that connects their agent to Slack, GitHub, Jira, Google Calendar, and a payment processor now runs five MCP servers. Each needs configuration, auth credentials, and monitoring. The n+1 problem that MCP solved at the endpoint level (too many API paths) reappears at the server level (too many running processes). Debugging which server returned an unexpected result requires tracing through the agent's tool call log, matching it to the correct server, and inspecting the underlying request.

Latency overhead. A direct API call is one network round trip. An MCP tool invocation adds at least one additional hop: agent to MCP server, then server to upstream service. For local stdio transport, the overhead is sub-millisecond and negligible. For remote HTTP servers, the auth handshake and network hop can add 50-200ms per invocation. In a chain of 10 tool calls, that compounds to 0.5-2 seconds of added latency, enough to matter in user-facing applications.

The curation bottleneck. Someone still decides which tools to expose and how to describe them. A tool named "process" with no further context is worse than a documented REST endpoint. The quality of an MCP integration depends entirely on whoever built the server. The protocol standardizes the transport layer, not the quality of what rides on it.

Auth surface area for remote servers. The MCP specification added OAuth 2.1 support for remote connections in early 2025. Agents connecting to remote servers need to handle authorization flows, token refresh, and scope management. For teams already managing API keys for direct integrations, adding an OAuth layer to each server connection increases the total auth surface rather than simplifying it.

Three workflows where calling the API directly is the better choice

MCP adds value when the agent needs to discover tools, when the service surface is large, or when multiple capabilities need to coordinate dynamically. But for a meaningful set of automation patterns, the direct call is simpler, faster, and easier to debug.

Fixed integrations with known endpoints. If a workflow always calls the same three Slack methods (post message, list channels, get user info), wrapping them in an MCP server adds infrastructure without adding capability. The workflow already knows what to call. Runtime discovery is unnecessary.

A customer onboarding workflow in a Chase Agents workspace shows how both patterns coexist. The first step sends a welcome email through SendGrid's mail endpoint. The second step creates a CRM record through a fixed HubSpot call. Both steps have known inputs, known outputs, and zero need for tool registration at runtime. Routing these through intermediary servers would add latency and a maintenance dependency with no corresponding benefit. The third step connects to an MCP server that gives the AI access to the company's internal documentation. The agent searches the knowledge base, selects relevant setup instructions, and generates a personalized onboarding guide. That step needs dynamic discovery because the available documentation changes weekly and the agent must adapt to whatever content currently exists.

High-throughput event pipelines. Processing 10,000 webhook events per hour through a direct call costs one HTTP request per event. Adding an intermediary server doubles the request count and introduces a scaling bottleneck. For batch operations and event-driven pipelines, the extra layer has no role.

Simple CRUD operations. Creating, reading, updating, and deleting records through a focused service with 5-10 endpoints doesn't benefit from dynamic tool registration. The workflow engine already knows the complete surface.

The 18-month trajectory

MCP adoption is tracking a curve similar to containerization between 2014 and 2016. Early adopters are building community servers for popular services: Stripe, GitHub, Slack, and Google Workspace all have active open-source implementations. Aggregation platforms are emerging that host pre-built servers as managed services, which cuts the "build your own" phase down to a configuration step.

The inflection point arrives when service providers ship official MCP servers alongside their REST documentation. Stripe, Twilio, and Shopify have the developer relations infrastructure to do this within the next year. When that happens, the build-vs-consume decision reverses: instead of wrapping existing APIs in custom servers, teams will adopt the official interface as their primary integration path for any workflow step where an AI agent is the caller.

For teams building automation today, the decision criteria are clear. Use MCP where tool discovery and dynamic capability matter. Use direct API calls where they don't. A Chase Agents workflow processing insurance claims does exactly this: the classification step calls a fixed API to pull the policy record, because the endpoint never changes. The next step connects to an MCP server so the AI can search across adjuster notes, precedent databases, and compliance checklists that update monthly. Same workflow, both protocols, each step using the interface that fits its actual requirements.

The two protocols are complementary layers in the same stack. The agent calls the one that matches the task.