MCP Still Has to Prove Its AI Value
Mayura launched in July 2025 with a question our founder had been asking since MCP was announced:
What problem are we having that MCP is the answer?
Our founder had already spent years at Microsoft as a data and AI forward deployed engineer, building a multi-agent system out of Minecraft bots at a 2023 hackathon, before "agents" was a product category, and in 2024 an agent management system for running fleets of AI agents, before agent-ops had a name. What that work taught was how much an agent can accomplish with a shell, an API, a CLI, or decent documentation.
One year into building Mayura, our answer has changed only slightly.
MCP can be a useful adapter convention for AI hosts. The much larger story being told about it still outruns the evidence.
The strongest case is host convenience
MCP gives general-purpose AI hosts a common way to connect to external tools and context. A host such as Claude Code, Cursor, or Visual Studio Code can implement one client interface. A software provider can expose one MCP server to participating hosts. A user may get a more consistent setup flow.
That is real value. It is ecosystem coordination.
It is also familiar value. OpenAPI standardized machine-readable API descriptions. OAuth standardized delegated authorization. Language Server Protocol standardized communication between development tools and language intelligence. Plugin systems have long separated hosts from extensions.
MCP applies a similar pattern to AI hosts. The protocol did not make APIs callable, documentation readable, or tools discoverable in the broad sense implied by much of the marketing.
The official MCP architecture describes a */list discovery pattern, such as tools/list and resources/list, for enumerating a server's tools, resources, and prompts. Those methods enumerate capabilities after a client has connected to a known server. A person or organization still finds the server, evaluates the provider, configures the client, authenticates, grants permissions, and decides which capabilities should be available.
That is manual customer experience supporting standardized agent experience.
AX still rests on DX and CX
The current conversation often treats agent experience as a new surface that can compensate for old software interfaces. In practice, AX inherits their quality.
The developer experience still needs coherent operations, stable schemas, useful errors, and accurate documentation. Many MCP servers are adapters over existing APIs, so every weakness in the underlying contract remains. The adapter adds another description and another boundary to maintain.
The customer experience still carries discovery, trust, setup, authentication, authorization, and support. Automatic connection to unknown servers would create obvious security problems. Anthropic's own connector security guidance tells users to connect trusted servers, review permissions, and disable tools they do not need. Those are responsible requirements, and each is an explicit customer step.
Once a company has built sound DX and guided the customer through sound CX, a capable agent can often use the resulting API, CLI, or documentation directly.
MCP may shorten the final host integration. It does not replace the foundation beneath it.
Agent capability keeps weakening the mandate
The original argument for MCP assumed that models needed carefully packaged tool definitions to interact with software reliably. Agent capability has moved in the opposite direction.
Modern coding agents navigate repositories, search documentation, run shell commands, write small programs, inspect responses, and repair their own integration attempts. The more capable the agent becomes, the less translation it needs between an existing software contract and the work it is trying to complete.
Anthropic exposed this tension in its article on code execution with MCP. Its example reduced tool-related context from 150,000 tokens to 2,000 by representing MCP tools as code and letting the agent load only what it needed from the filesystem. The article points to context management, tool composition, and state persistence as problems with established software-engineering solutions.
Cloudflare reached the same conclusion in its Code Mode work. It converts MCP tools into a TypeScript API and asks the agent to write code against it, on the reasoning that models "are better at writing code to call MCP than at calling MCP directly," because they have seen far more real code than tool-call examples. Cloudflare keeps MCP itself, as the uniform layer for connectivity, authorization, and documentation, and changes only how the agent uses what it finds.
That is a revealing direction. Anthropic, which introduced MCP, and a host infrastructure vendor both kept MCP and changed the calling pattern: when the tool-call abstraction gets in the way, let a capable agent write code.
Adoption does not settle the value question
Standards can gain broad support because large hosts benefit from a shared convention. Vendors then support the convention because the hosts do. That cycle can produce substantial adoption without proving that every software product had an unmet problem.
This is why lists of supported clients, server counts, foundation governance, and enterprise features do not answer our original question. They show that MCP is becoming institutionalized. They do not establish that a SaaS provider needs an MCP server to remain relevant, or that customers will install one, or that an agent would have failed with the provider's existing interfaces.
The decision should begin with observed friction:
- Are customers asking to use the product through several MCP-compatible hosts?
- Are host-specific integrations creating meaningful maintenance work?
- Does the MCP path complete important workflows more reliably than the API, CLI, or documentation path?
- Will enough customers complete the setup and authorization flow to justify another public interface?
If the evidence says yes, build the adapter. If the evidence is absent, strengthen the interface the product already has.
Conviction should survive contact with operations
Our founder came away curious and unconvinced after reading the specification closely last year, because the excitement never connected to a constraint the work had actually produced. That stayed true through Mayura's launch, because nobody we asked could supply the missing example. Another year of building Continuous Intelligence at Mayura, running always-on against real sources, has given us more agents, more tools, and more real workflows, none of which expose a product surface to third-party AI hosts. On that workload it has not produced a need for MCP.
That does not make the protocol worthless. It makes its value specific.
MCP helps participating hosts and providers coordinate around an adapter. For some products, that convenience will justify the cost. For many teams, capable agents using well-designed APIs, CLIs, and documentation will continue to work just fine.
The industry can keep expanding the standard. Software companies should still demand a concrete answer before expanding their architecture.
What recurring problem will MCP remove for our users that our existing interface does not already solve?
That is the test we apply to our own work. Mayura is Continuous Intelligence: it reads the feeds you follow, the inboxes you point it at, the web pages that matter to you, and the PDFs they link to, and each morning's answers are assembled before anyone asks. If you are weighing whether an MCP server earns a place in your architecture, start with our services and we will work it through against your own stack.