Why do we even need MCP?
Last week, I shared why MCP won't magically solve all problems that exist in software integrations. The question I didn't address was why MCP is even needed in the first place. Creating new standards without very good reason is a great way to create fragmentation (see above). Agents, at first glance, don't seem like a good enough reason.
Stupid not-so-good reasons why MCP needs to exist
MCPs add context: One could argue that MCP provides nothing that a well-specified OpenAPI configuration doesn't already provide. I was in this camp for a while, particularly since even if MCP theoretically adds more context to a certain endpoint (the most common defense), a good OpenAPI definition could do that too. The specification contains description fields for basically every entity (232 mentions of "description"), and there's no reason to believe people will magically start using them for MCPs when they haven't done so for normal OpenAPI definitions.
MCPs are stateful: So what? If anything, this causes more problems at this stage than it solves (see this discussion). Most connections don't require statefulness, and the only implementations I can see right now where stateful connections are an advantage are change subscriptions. Nothing that GraphQL or webhooks couldn't solve just as well for specific use cases.
MCP definitions are less complex: The most pragmatic explanation I've seen is that most APIs are simply too complex for agents to grasp. This is the perfect opportunity to share this gem, the JIRA's OpenAPI definition, which doesn't even fit into the context window of most state-of-the-art LLMs. However, given the ongoing increase in context window size and LLM capabilities, this seems like a very time-bound discussion (remember RAG?). So, are we getting hyped about a protocol that only exists because agents aren't capable enough yet?
The only reason MCP should exist: Capabilities, not endpoints
The fundamental difference between agentic tools and API endpoints is the separation of concerns present in most modern REST APIs. In practice, this means that one endpoint serves one particular purpose for the given data model, and most use cases require multiple, often different or chained API calls to do anything useful.
A good example is the Stripe API. Say we want to create an invoice and bill it to a specific customer (jack@acme.com) for a service our agent provided. This entails:
GET /v1/customers/search: Calling the customers endpoint to identify Jack's customer ID based on their email
POST /v1/invoices: Create an invoice for the customer ID with some basic identifying information
POST /v1/invoiceitems: For each item we need to bill, create a line item on the invoice
POST /v1/invoices/:id/finalize: Finalize the invoice to prepare for collection at the due date or right now
This is manageable for a software engineer: reading the entire API documentation and setting up a workflow once with their SaaS tool. For an agent with even a 98% task success rate, executing this flow with two line items would give us a 90% completion rate, meaning every 10th invoice generation fails. Not great.
Even more importantly, an agent providing a service to our customers shouldn't be concerned with all the intricacies of how the Stripe API works. What matters is that the agent completes its primary task, and the invoice reliably gets sent out as a secondary outcome. From a user perspective, the capability ("generate an invoice for this service") matters far more than the implementation details.
This is why MCP is needed. MCP is the abstraction layer that sits between APIs and our agents, giving our agents the capabilities these APIs provide rather than forcing them to navigate endpoint orchestration.
I’m not saying that MCP is the only way this can be achieved - We can use OpenAPI definitions as tools, even to generate MCP servers. We can create a GraphQL API to abstract workflows. The important part is: to get agents to work well, the best approach is to identify the use cases that matter for the LLM, and give the agent the capabilities to fulfill these in the simplest, most abstract way possible. And MCP is a great way to do so.
Where this is headed
Even as agents improve in reliability, I predict that the pattern of abstracting complex workflows into simpler capabilities will likely become more established. This approach separates concerns, handles authentication securely, and works efficiently with large amounts of data.
I believe we'll see a convergence toward capability-oriented interfaces for agents, whether through MCP adoption or through extensions to existing standards. For developers building agent-powered applications today, the focus should be on creating these capability abstractions regardless of the underlying protocol. The agents, and more importantly, your users, will thank you for it.
The good news is that tools will emerge to make this easier, sooner or later. Shameless shoutout to our own open-source project, superglue.cloud, that you can use very soon to spin up your own, capability-driven MCP. Let us know how that goes.