MCP Is the USB Port, Not the Product

Sovereign context operating model

An AI agent is only as good as the context it can reach. For a regulated enterprise, that context — the architecture repository — is also one of its most sensitive assets.

The operating model that matters is not "expose the repository over MCP"; it is "govern what context leaves, to whom, and under which residency and audit constraints".

• Decide which object types are queryable, and which are never exposed
• Keep context fresh: reconcile the repository against live sources, not a yearly snapshot
• Make every answer traceable to a governed source the user is entitled to see

Execution focus for this topic

When everyone exposes an MCP, "we have an MCP" is no differentiator — the value is the governed context behind the port.

Use this page as a decision support asset: align stakeholders, validate trade-offs, and connect architecture choices to measurable business outcomes.

• Primary query focus: MCP Is the USB Port, Not the Product
• Decision scope: strategy, governance, operating model, and execution constraints
• Expected output: clear next actions with ownership and measurable indicators

"We have an MCP" is not a feature

Walk any EA vendor demo in 2026 and you will hear it within five minutes: "and of course, we support MCP." It is delivered like a punchline. It should be delivered like a footnote.

The Model Context Protocol is a standard — an open, shared way for an AI model to talk to an external system. Standards are designed to be universal. The moment something becomes a standard, having it stops being a selling point and becomes an expectation. "We have an MCP" is, structurally, the weakest possible differentiator: it is true of everyone, soon.

The right analogy: HTTP, USB, the wall socket

Think about how you choose a laptop. You do not choose it because it has a USB port — every laptop has one. The port is how the value gets in and out; it is not the value. You choose on the screen, the battery, the chip, the build.

MCP is the USB port of enterprise AI. It is also the HTTP of agent-to-system communication, the wall socket of context delivery: indispensable, invisible, and utterly uninteresting as a buying criterion. Nobody picks a website because it "supports HTTP." Nobody should pick an EA platform because it "supports MCP." The protocol is the commodity. The decision is made on what flows through it.

• USB doesn't make a device good — it just lets a good device connect
• HTTP doesn't make a site valuable — the content behind it does
• MCP doesn't make context useful — the governed data behind it does

When everyone exposes a port, the port stops mattering

This is not hypothetical. The major platforms are converging on MCP fast. Ardoq, LeanIX, ServiceNow and SAP are each, in their own way, moving to expose their architecture and operational data through standard AI interfaces. We name them neutrally — as fellow adopters of the same protocol, because that is exactly the point.

When four or five serious vendors all ship an MCP server, the checkbox goes flat. "Do you support MCP?" becomes a yes-from-everyone question, like "do you support single sign-on?" The market quietly resets: the protocol is assumed, and the real comparison moves one layer down — to the quality of what each port exposes.

Stop selling the port. The value is the context behind it.

If the port is a commodity, the product is the context. And context is where the honest, hard, defensible differences live. Two vendors can both speak fluent MCP and deliver wildly different value, because one is piping a fresh, governed, sovereign model and the other is piping an 18-month-old snapshot to a US-cloud LLM.

These are the questions that actually separate offerings — and not one of them is answered by the word "MCP":

• Quality: is the model accurate and trustworthy, or a half-maintained diagram graveyard?
• Freshness: is it living context, or a stale snapshot an agent will confidently misread?
• Governance: is access role-scoped, permission-aware and audit-logged?
• Sovereignty: when an agent queries it, where does your architecture data physically go?

Sovereignty is the axis the port can't show you

For a regulated EU institution, the last bullet is the one that turns a demo into a DORA, CSSF, GDPR or EU AI Act conversation. An enterprise architecture map is a near-complete blueprint of the organization. Connecting it to an AI agent over a perfectly standard MCP, while the data round-trips to an external LLM, is a governance decision dressed up as a protocol feature.

This is where ArchiLU plants its flag — and where we are deliberately honest about what is shipped versus where we are heading. We do not claim a sovereign MCP server today; building one, data-residency-aware by design, is our conviction and roadmap. What exists now is the part that makes any future port worth plugging into: a connected EA model of capabilities, application portfolio and dependencies, EU-region or on-premise hosting you control, native French and English, and published pricing (1,290 / 2,500 EUR/month, Enterprise on quote, unlimited users). Build the context first; expose the port last. A standard over a stale, ungoverned repository is worthless — and it is the part nobody can copy with a checkbox.

Regulated AI context KPIs

Measure whether your context is trustworthy and governed, not how many queries the agent runs.

• Context freshness: median age of architecture objects vs live reality
• Share of answers traceable to a governed, permission-scoped source
• Sensitive object types covered by redaction/residency policy
• Audit coverage: prompts and responses logged and reviewable

Common mistakes

Most MCP-for-EA initiatives fail on context quality and governance long before they fail on the protocol.

• Exposing the full architecture repository to external LLMs without data-residency controls
• Treating MCP as the differentiator instead of the governed context behind it
• Connecting an 18-month-old, hand-maintained repository an agent cannot trust
• No permission-awareness, logging, or redaction of sensitive object types

Practical checklist

Run this before connecting any AI agent to your architecture repository.

• Confirm where prompts and responses go, and whether data stays in your region
• Enforce permission-aware access so the agent only sees what the user may see
• Classify and redact sensitive object types (vulnerabilities, data flows, controls)
• Log prompts and answers for audit, and keep a human in the loop for any change