MCP is one of the most thoughtfully scoped technical standards to come out of the AI ecosystem. That scope is intentional. Understanding exactly where MCP stops is the precondition for understanding what needs to be built on top of it.
This post is about that boundary.
What MCP actually does
MCP is a JSON-RPC 2.0 protocol that defines three primitives a server can expose: tools, resources, and prompts. It turns the N x M integration problem between LLM applications and external tools into N + M. Build a server once, and any compliant client can use it.
The adoption numbers are striking. In sixteen months, MCP crossed 110 million monthly SDK downloads and more than 10,000 community-built server implementations. Every major AI vendor now supports it. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI. In April 2026, the AAIF held the MCP Dev Summit North America in New York City with 1,200 attendees, double the previous summit. MCP co-creator David Soria Parra compared MCP's adoption speed to React: React took three years to reach similar numbers. MCP did it in sixteen months.
The mental model that captures it: MCP is the closest thing the LLM ecosystem has to USB-C. A single standard that lets any compliant client talk to any compliant server, without bespoke per-app, per-tool wiring.
A frequently discussed companion protocol is A2A, released by Google in April 2025. The two are complementary, not competing. MCP defines how agents interact with tools. A2A defines how agents collaborate with each other.
So we have the agent-to-tool layer. We have the agent-to-agent layer. Both are under Linux Foundation governance. Both are being adopted at scale.
Here is what neither of them addresses.
The problem they were not designed to solve
Consider a legal AI pipeline that needs to do the following:
- Classify an incoming contract by type (NDA, MSA, SOW, license agreement)
- Extract all parties, obligations, and termination clauses
- Score the extracted obligations against a compliance policy
- Generate a risk summary
You have four models. Each was trained by a different team. Each has a different input format, a different output schema, and different field names for the same concepts.
- The classifier expects a flat string
- The extractor expects a structured JSON object with a
document_textfield nested undercontent - The scorer expects an array of obligation objects in a proprietary schema
- The summarizer expects a
contextobject with specific metadata fields
None of these models speak to each other natively. MCP does not change this. MCP connects each model to your agent as a tool. What it does not do is define how the output of model A becomes the input of model B when A and B have fundamentally different schemas.
The result: every team building this kind of pipeline writes custom translation code between each model pair.
| Models in pipeline | Custom connectors required |
|---|---|
| 4 models | 6 connectors |
| 10 models | 45 connectors |
| 20 models | 190 connectors |
Each connector is written once for a specific pair, tested for that pair, and breaks whenever either model updates its schema.
Fivetran's 2026 enterprise data infrastructure benchmark (based on a survey of 500 senior data and technology leaders at organizations with more than 5,000 employees) found that 97% reported pipeline failures slowing their AI programs, with data teams spending 53% of engineering time on pipeline maintenance. That survey covered data pipelines broadly, not AI model pipelines specifically. But anyone who has built multi-model pipelines in production will recognize the pattern.
The maintenance burden is not a people problem. It is a structural problem. There is no shared schema between heterogeneous specialist models, so every connection requires bespoke engineering and every update requires bespoke maintenance.
This is the gap. It is not in MCP's scope, and it should not be. MCP is a connectivity standard. Schema translation between heterogeneous specialist models is a different problem at a different layer.
Why existing tools do not solve this
The existing routing tools solve a related but different problem. OpenRouter routes between general-purpose LLMs: GPT-4o, Claude, Gemini. These models are largely interchangeable at the interface level. You swap one for another and the calling code mostly still works because they all accept similar inputs and produce similar outputs.
Specialist models are not interchangeable. A fine-tuned legal NER model and a clinical ICD coding model have nothing in common at the schema level. Their inputs are different shapes. Their outputs are different shapes. The concepts they operate on have different names in their respective APIs. Routing between them is not a matter of picking a cheaper or faster model for the same task. It is a matter of making fundamentally incompatible systems compose correctly.
| Tool | What it solves | What it does not solve |
|---|---|---|
| OpenRouter | Cost/quality routing between interchangeable LLMs | Schema translation between specialist models |
| LiteLLM | Unified gateway for general-purpose LLM APIs | Heterogeneous specialist model interoperability |
| Martian / NotDiamond | Prompt routing to the right general-purpose model | Domain-specialist model composition |
| MCP | Agent-to-tool connectivity | How incompatible model outputs become compatible model inputs |
None of them address heterogeneous specialist schema translation because they were not built for it.
What a solution looks like
The approach that makes sense is a canonical intermediate representation: a typed, versioned message format that sits between models in a pipeline. Each model gets an adapter with two functions.
- ingress converts the canonical format into whatever the model natively expects
- egress converts the model's output back into the canonical format and appends a provenance record
Write two functions once per model. The model can now interoperate with every other model in the ecosystem permanently, regardless of what schemas they use natively. Add a new model to your pipeline and you write two functions, not N new connectors.
The adapter contract has to be strict to be useful. The functions must be pure: no network calls inside ingress or egress, no persistent state. The egress function must not modify any provenance record written by a previous model in the chain. The compliance envelope established at the start of the pipeline must be carried through unchanged. These constraints are what make the system composable rather than just connected.
A routing layer on top of this can then make decisions that improve over time. Given a task type, a domain, a latency budget, and a compliance requirement, which registered model has the strongest production track record? That decision gets better as routing signals from real pipeline executions feed back into the routing weights. Declared performance estimates on model cards are a starting point. Observed production performance across many organizations is ground truth.
Why now
At the MCP Dev Summit in April 2026, David Soria Parra said something worth sitting with:
"Behind every corporate firewall, we're quietly wiring MCPs to systems of record and company data all day long. Your Salesforce CRM, your Jira tickets, internal wikis, Snowflake warehouses, HR systems. You never really see or hear about it on Twitter or Hacker News."
That observation applies directly to specialist model pipelines. The integration work is happening, silently, inside every organization that runs more than two specialist models in production. It is being solved independently, in isolation, in ways no one else can reuse.
The developers doing that work are the MCP community's closest neighbors. They already understand protocol layers, adapter patterns, and registry architectures. MCP built that conceptual infrastructure. The moment for a schema translation standard to emerge on top of it is exactly now, while the ecosystem is actively building and the patterns are not yet set.
What we built
We built SYNAPSE: a canonical intermediate representation and adapter framework for heterogeneous AI model pipelines.
The canonical IR is an open specification under CC BY 4.0. The adapter SDK is MIT licensed. The specification covers nine task types, eight domains, a five-layer caching architecture that keeps per-hop overhead under 1ms in steady state, a compliance envelope for GDPR, HIPAA, SOX, and PCI-DSS pipelines, and a calibration layer that improves routing decisions from real production signals over time.
Install the Python SDK:
pip install synapse-adapter-sdk
Writing an adapter looks like this:
from synapse_sdk import AdapterBase, CanonicalIR
from typing import Any
class MyModelAdapter(AdapterBase):
MODEL_ID = "my-org/my-model-v1.0"
ADAPTER_VERSION = "1.0.0"
def ingress(self, ir: CanonicalIR) -> dict[str, Any]:
return { "input": ir.payload.content }
def egress(self, output: dict, original_ir: CanonicalIR, latency_ms: int) -> CanonicalIR:
updated = original_ir.copy()
updated.provenance.append(self.build_provenance(
confidence=output["score"],
latency_ms=latency_ms,
))
return updated
Validate your adapter against 13 conformance rules and 20 standard fixtures:
synapse-validate --adapter my_module.MyModelAdapter --all-fixtures
Links:
- Specification: github.com/synapse-ir/spec
- Registry server: github.com/synapse-ir/registry
- Reference adapters: github.com/synapse-ir/adapters
- Docs: synapse-ir.github.io/adapter-sdk
If you are building on top of MCP and running into schema incompatibility between specialist models, this is what SYNAPSE is for. We are actively looking for developers who have the problem and want to write the first community adapters. The BOUNTIES.md lists the models where adapters are most wanted.
SYNAPSE does not compete with MCP. It builds on the layer MCP created.
Top comments (0)