Enterprise architects have been building abstraction layers between systems and consumers for decades. Most of those layers failed. MCP might be the one that works — but only if you understand why it's different from everything that came before it.

Thesis: MCP is emerging as a semantic data layer — an abstraction between systems of record and any consumer that makes capabilities discoverable and self-describing. This is the enterprise service bus done right, because the intelligence lives in the consumer, not the layer.

This is Post 2 of 6 in "The Interface Inflection" series. If you haven't read Post 1: Interfaces Are Changing, start there for the foundational shift in what "interface" means.

What "Semantic Data Layer" Actually Means

A semantic data layer sits between producers (your platform APIs, databases, systems of record) and consumers (agents, apps, scripts, partner integrations). It provides five things:

  1. Abstraction — consumers don't need to know the underlying API structure, endpoint paths, or authentication quirks
  2. Semantics — capabilities are described in meaning, not just syntax; a natural language description accompanies every schema
  3. Discovery — consumers enumerate what's available at runtime, not by reading documentation months after it was written
  4. Negotiation — consumers determine how to use capabilities contextually, selecting and composing tools based on the task at hand
  5. Governance — access control, validation, rate limits, and guardrails live at the layer, not scattered across individual APIs

None of these are new ideas individually. What's new is having all five in a single protocol that both humans and AI agents can consume.

The Service Bus Comparison (And Why It's Different)

If you've been in enterprise architecture for any length of time, MCP as a semantic layer sounds familiar. It should. The comparison to enterprise service buses is apt — but the outcome is fundamentally different.

Property ESB MCP Semantic Layer
Abstraction Message transformation Semantic capability description
Discovery UDDI registry (static) Runtime tool listing (dynamic)
Consumer Known applications Unknown agents (open-ended)
Contract WSDL/XSD (rigid) JSON Schema + NL description (flexible)
Routing Predefined rules Agent-determined (contextual)
Scaling Centralized bottleneck Distributed (per-server)
Intelligence Dumb pipe (tried to be smart) Consumer brings reasoning

The last row is the one that matters most.

ESBs failed because they centralized logic. Routing, transformation, orchestration — all of it lived inside the bus. The bus became the bottleneck, the single point of failure, and the place where complexity went to hide. Every new integration made the bus smarter, heavier, and more fragile.

ESBs failed because they centralized logic. MCP works because it centralizes description while distributing reasoning. The intelligence is in the LLM, not the layer.

MCP inverts this. The layer stays thin — it describes capabilities, validates inputs, enforces guardrails. The consumer (an LLM, an app, a script) brings the reasoning. It decides which tools to call, in what order, with what parameters. The semantic layer never routes, never transforms, never orchestrates.

As long as MCP stays a description layer and resists the temptation to become a routing or orchestration layer, it avoids the ESB trap.

Where MCP as Semantic Layer Makes Sense

Not every system needs a semantic layer. The overhead is real — schema negotiation, discovery roundtrips, abstraction maintenance. Here's where it earns its keep:

  • Multi-consumer platforms — when your web app, CLI, agents, and partner integrations all need the same capabilities, describing once beats integrating N times
  • Capability-rich domains — dozens of agents, patterns, templates, and workflows are too much for any single consumer to hardcode
  • Rapidly evolving APIs — new endpoints appear frequently; consumers auto-discover instead of waiting for integration updates
  • Cross-org consumption — external consumers shouldn't touch raw APIs; the semantic layer provides a governed surface
  • Composable workflows — consumers need to chain capabilities in novel, unpredictable ways

Where It Doesn't Make Sense

  • High-throughput data pipelines — MCP adds per-call latency that bulk operations can't absorb
  • Real-time streaming — request-response doesn't suit event streams; use purpose-built protocols
  • Simple CRUD with known consumers — if you have three known apps calling a REST API, the abstraction overhead isn't worth it
  • Performance-critical hot paths — schema negotiation on every call adds milliseconds you may not have
  • Binary/media transfer — MCP is optimized for structured data exchange, not bulk file transfer
  • Tight coupling by design — some microservice-to-microservice calls intentionally couple for performance and simplicity

Decision Framework

When evaluating whether MCP adds value as a semantic layer, walk through this:

flowchart TD
    A[Is the consumer unknown\nor heterogeneous?] -->|Yes| B[Do consumers need to\ncompose capabilities?]
    A -->|No| C[Is performance critical?]
    B -->|Yes| D[MCP Layer\nstrong fit]
    B -->|No| D
    C -->|Yes| E[Direct API\nskip MCP]
    C -->|No| F[MCP optional\nconvenience layer]

    style D fill:#2d6a4f,color:#fff
    style E fill:#9d4444,color:#fff
    style F fill:#5a5a8a,color:#fff

The key question is consumer heterogeneity. If you know exactly who calls your API and that set is stable, direct integration is simpler. Once consumers are unknown, diverse, or likely to grow, the semantic layer pays for itself.

The Layered Architecture

The architecture is straightforward. Three layers, clean boundaries:

block-beta
    columns 1

    block:consumers["Consumers (Equal Peers)"]
        columns 6
        WebApp["Web App"]
        Claude["Claude"]
        Gemini["Gemini"]
        Cursor["Cursor"]
        CLI["CLI"]
        Auto["Autobuilder"]
    end

    block:mcp["MCP Semantic Layer"]
        columns 3
        Discover["Discovery &\nSchemas"]
        Validate["Validation &\nGuardrails"]
        Govern["Governance &\nAccess Control"]
    end

    block:apis["Platform APIs / Systems of Record"]
        columns 3
        REST["REST APIs"]
        GraphQL["GraphQL"]
        DB["Databases"]
    end

    consumers --> mcp
    mcp --> apis

The critical detail: the web app and the autobuilder sit alongside Claude, Cursor, and Gemini as equal peers. They are not deprecated, inferior, or legacy — they are valued interfaces that happen to consume the same semantic layer. The point is a multi-consumer ecosystem where no single head is privileged.

Real Example: How We Use This Today

The Ema MCP toolkit exposes the full AI employee platform through a semantic layer:

  • 6 tools: persona management, workflow deployment, catalog browsing, environment sync, environment info, feedback
  • 35+ resources: agent catalogs, workflow schemas, anti-patterns, templates, guides
  • 17 prompts: persona creation, workflow operations, requirements clarification, onboarding

This surface is consumed equally by:

  • The Ema web application — polished visual interface for guided workflows
  • The autobuilder — automated persona creation with guardrails
  • Cursor IDE — developer workflow for building and managing AI employees from the editor
  • Claude Desktop — conversational management of AI employees
  • Standalone scripts and CLI tools — automation and ops tasks
  • Other agent frameworks — Gemini, custom pipelines

None of these consumers hardcode the platform API. They discover and negotiate through the semantic layer.

The proof that this works came recently: an agent consumer noticed a new API endpoint for data copying that wasn't part of any pre-built integration. It discovered the endpoint through the semantic layer, understood the required inputs from the schema, and started using it — no integration code written, no deployment needed. That's the semantic layer earning its keep.

Governance: Who Controls the Semantic Layer?

A semantic layer without governance is a liability. Four principles keep it honest:

Schema accuracy is a correctness issue, not a documentation issue. If the MCP schema says a tool accepts a persona_id string but the underlying API expects an integer, every consumer breaks. Treat schema drift like you treat type errors — fail the build.

Version the semantic layer like you version APIs. Breaking changes to tool schemas, removed capabilities, renamed parameters — these need the same versioning discipline you apply to REST endpoints.

MCP as layer, not gateway. The moment your MCP server starts routing requests, transforming payloads, or orchestrating multi-step flows internally, you've rebuilt the ESB. Keep the layer thin: describe, validate, delegate.

Fingerprint-based optimistic locking prevents stale-state issues. When multiple consumers modify the same resource, a fingerprint mechanism ensures no one overwrites changes they haven't seen. This is especially critical when agents operate concurrently. For more on this pattern, see MCP: From Hardcoded to Live Data.

The ESB Counterargument

The inevitable objection: "ESBs failed, this will too."

ESBs failed because they tried to centralize routing, transformation, and orchestration inside the bus. The bus got smarter with every integration, accumulating logic that should have stayed in the endpoints. Eventually, the bus was the most complex component in the architecture — and the hardest to change.

MCP's intelligence distribution is fundamentally different. The semantic layer describes. The consumer reasons. The platform executes. No component accumulates logic that belongs elsewhere.

This holds as long as MCP stays disciplined. The risk is real — the gravitational pull toward "let's add routing logic to the MCP server" is strong. Resist it. The moment MCP becomes smart, it becomes the next ESB.

What to Do Next

  • Audit your consumer landscape. Which of your platform capabilities serve multiple consumers today? Which will tomorrow?
  • Assess discovery value. For multi-consumer capabilities, does MCP add meaningful discovery and composition value, or is a typed SDK sufficient?
  • Apply the decision framework. Don't wrap everything in MCP. Use it where consumers are heterogeneous and capabilities are composable.
  • Keep your MCP layer thin. Description, validation, governance. Not routing, transformation, orchestration.
  • Version your MCP schemas. Apply the same discipline you use for API versioning. Breaking changes need migration paths.
  • Treat schema accuracy as a build-time check. If the schema drifts from the underlying API, fail early.

Next in the series: Post 3 explores the headless architecture pattern — what happens when every app, agent, and script becomes an equal consumer on a shared capability layer.

Related reading: The MCP Mental Model for core primitives, MCP: From Hardcoded to Live Data for dynamic data patterns, and the MCP specification for protocol details.