I've spent the last six months reading the Model Context Protocol spec, building on top of it, and arguing with people about it. I've come to a position that I think is defensible: MCP is probably the most important protocol in AI right now, and also deeply incomplete in ways that matter.
Both of those things are true at the same time. Let me explain.
What MCP Gets Right
If you haven't dug into MCP, here's the short version. It's a protocol that lets AI models invoke tools on external servers. A client (the AI) connects to a server (the tool provider), discovers available tools, and calls them with structured arguments. The server returns structured results. There's support for streaming, resource management, and prompt templating.
The design is clean. I mean that as genuine technical praise. The tool invocation model is well-specified. JSON-RPC transport works. The capability negotiation on connection is smart. Streaming support means long-running operations don't time out. The type system is flexible enough to express complex tool interfaces without being so complex that implementations diverge.
When I compare MCP to the ad-hoc tool calling that existed before it (function calling specs baked into each model's API, no standardization, no streaming, every integration a snowflake), the improvement is real. MCP does for agent-to-tool communication roughly what TCP/IP did for computer-to-computer communication. It gives us a shared transport layer that everyone can build on.
That's a big deal. It's worth recognizing.
What's Not in the Spec
Now here's where I start having opinions. TCP/IP was a transport layer. It didn't tell you how to find the computer you wanted to talk to (DNS did that). It didn't tell you how to format your messages (HTTP did that). It didn't handle identity or payments or trust. Those were all built as separate layers on top.
MCP is in the same position. It's a transport layer for tool invocation. But if you're building multi-agent systems, you need a lot more than tool invocation. And right now, the layers above MCP are either missing or being improvised by each team independently.
Here's what I see missing:
Discovery
MCP assumes you already know the server you want to connect to. The spec has no mechanism for an agent to say "I need a tool that can do X" and find matching servers. Today, discovery happens by a human reading a GitHub README, copying a URL, and pasting it into a config file. That's fine for a developer setting up their own tools. It's a dead end for autonomous agents that need to find services dynamically.
Compare this to the web. TCP/IP didn't include DNS, but DNS was built early and universally adopted. The agent ecosystem needs its equivalent of DNS, and it doesn't have one yet.
Payments
The MCP spec says nothing about money. If a tool costs something to use, there's no standard way to express that, no way to negotiate price, no way to complete a transaction. Every paid MCP server has to invent its own billing mechanism. Most just use traditional API keys tied to billing accounts, which means a human has to set up every paid connection in advance.
For agents to operate autonomously, they need a way to pay for services on the fly. The x402 protocol (HTTP 402 with USDC on Base) is one answer. There might be others. But the point is that MCP leaves this entirely unaddressed, and it's a hard constraint on what autonomous agents can actually do.
Verification and Trust
When an MCP client connects to a server, it has no way to verify that the server is who it claims to be or that it will behave as advertised. The spec includes capability negotiation (the server declares what tools it offers), but there's no trust layer. No identity verification. No service-level guarantees. No reputation system.
This matters more than it might seem. In a world where agents are connecting to arbitrary MCP servers, the security implications are serious. An MCP server has access to whatever context the client sends. A malicious server could exfiltrate data, return misleading results, or rack up charges on services it calls downstream.
The web solved this (partially) with TLS certificates and certificate authorities. The agent world needs something similar, and MCP doesn't provide it.
Composition and Orchestration
MCP is point-to-point: one client connects to one server. But real agent workflows involve chains of operations across multiple services. Agent A needs to call Service B, pass the result to Service C, and aggregate the output. MCP doesn't have a concept of workflows, pipelines, or multi-service orchestration.
You can build orchestration on top of MCP. We do. But every team builds it differently because there's no shared abstraction for it.
The Layered Architecture I Think We Need
If MCP is the transport layer, what goes above it? I've been sketching this out, and I think it looks roughly like:
- Transport: MCP (tool invocation, streaming, capability negotiation)
- Discovery: A registry layer where agents can find services by capability, check metadata, compare options
- Identity: Verification of who's running a service, their track record, their security posture
- Payments: A protocol for price discovery, payment execution, and receipt verification (x402 is our bet here)
- Orchestration: Patterns for multi-service workflows, error handling across service boundaries, transaction rollback
This is roughly analogous to how the internet stack evolved. You had IP, then TCP, then DNS, then HTTP, then TLS, then all the application-layer protocols on top. Nobody designed the whole stack upfront. Each layer got built when the need became obvious.
I think the agent stack is going through the same process, just faster. MCP gave us the transport. Now we need the rest.
Where SocioLogic Fits
Full disclosure: SocioLogic is building several of these layers. Our Verified Agent Registry is a discovery and identity layer. Our x402 integration is a payment layer. Signal Relay is an MCP server that acts as a bridge between agents and our infrastructure. So I'm not a disinterested observer here.
That said, I genuinely don't think any single company should own the entire stack. MCP is better because Anthropic open-sourced it. The discovery layer will be better if multiple registries interoperate. The payment layer will be better if x402 becomes a standard that anyone can implement, not a proprietary protocol.
The protocols that win are the ones that are open enough for an ecosystem to form around them. I hope we're building in that direction. If we're not, someone should tell us.
What I'd Like to See
If I could wave a wand, here's what I'd want the MCP ecosystem to prioritize in the next year:
- A standard service descriptor format that lives alongside the MCP tool definitions. Something that includes pricing, SLA, identity, and trust metadata.
- A registry protocol that MCP clients can query to find servers. Not a single centralized registry, but a federated protocol that any registry can implement.
- Payment hooks in the MCP spec itself, or at least a sanctioned extension point for payment protocols to plug into.
- Security best practices that go beyond "use TLS." Guidance on sandboxing, capability restrictions, audit logging.
MCP is a strong foundation. The question is whether the community builds the upper layers as thoughtfully as the transport layer was built, or whether we end up with a mess of proprietary solutions that fragment the ecosystem.
I think it'll happen. But the window for getting this right is probably narrower than people think.