Thin vs Native MCP: Why the Model Behind the Server Decides Everything

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

Native depth matters, but for regulated finance it is incomplete without freshness and data-residency-aware governance.

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

• Primary query focus: Thin vs Native MCP: Why the Model Behind the Server Decides Everything
• Decision scope: strategy, governance, operating model, and execution constraints
• Expected output: clear next actions with ownership and measurable indicators

An MCP server is only as good as the model behind it

The Model Context Protocol is having its moment. Vendors are racing to announce that their enterprise architecture tool now "speaks MCP," as if the protocol were the product. It is not. MCP is a connector — a commodity, the USB port of AI. The interesting question is never whether a tool does MCP; it is what the agent can actually reason about once it is connected.

That depends entirely on the model the server exposes. Connect an agent to a flat table of applications and you get search. Connect it to a governed semantic graph and you get impact analysis. Same protocol, two different worlds. This is why the distinction between a thin MCP and a native MCP matters more than the MCP badge on the box.

Thin MCP: a wrapper that returns rows

A thin MCP is a lightweight API wrapper over the repository's tables. It exposes rows and attributes, and not much else. Ask it "show me the applications tagged payments" and it returns exactly that: a flat list of application records, perhaps with a few columns.

There is nothing wrong with this for simple lookups, and it is fast to build. But the agent on the other end has no idea what those applications support, who owns them, which controls cover them, or what breaks if one is decommissioned. The model behind the server is essentially a spreadsheet. The agent can read; it cannot reason.

• Exposes rows and attributes, not relationships
• Answers "what is tagged X" but not "what depends on X"
• No business semantics, no lifecycle, no governance context
• Cheap to ship, but the agent inherits a shallow world

Native MCP: a server that exposes the metamodel

A native MCP exposes the metamodel itself — the business semantics, the relationships, the lifecycle states, the governance rules that make an EA model more than a list. Ask the same payments question and a native server can trace a path: from the regulatory requirement, to the control that addresses it, to the business process it protects, to the applications that run it, to the infrastructure underneath.

Along that path it surfaces what a flat list cannot: an application with no named owner, a process with no mapped control, a dependency that points at an obsolete component. That is the difference between retrieving data and reasoning over a model. Bizzdesign deserves credit for raising this thin-versus-native framing publicly; it is a genuinely useful way to separate connectors that merely answer from connectors that actually inform.

• Traces requirement → control → process → application → infrastructure
• Surfaces ownership gaps and coverage gaps as it reasons
• Carries business meaning, not just field values
• Turns "connected" into "capable of impact analysis"

But native is not the finish line either

Here is where the industry conversation tends to stop — and where it should not. A native MCP makes answers richer, but rich is not the same as trustworthy. Two failure modes survive even a perfect metamodel, and both matter more in regulated finance than the thin-versus-native gap itself.

The first is freshness. A native graph that reflects an eighteen-month-old snapshot will reason confidently over a reality that no longer exists — naming owners who have left, controls that were retired, dependencies that were rerouted. Depth amplifies stale data; it does not correct it. The context has to be living to be worth querying, which is why we keep returning to the idea of an agent-ready, continuously refreshed repository.

The second is sovereignty. When an agent queries a native EA graph, it is reading a near-complete blueprint of the organization: the full system inventory, the critical dependencies, the obsolete components, sometimes the security measures. If the model behind the answer runs on a US-cloud LLM, that blueprint leaves your control. For a DORA-, CSSF- or EU-AI-Act-regulated institution, that is not a feature trade-off — it is a residency and governance problem. A truly capable MCP has to govern where the data goes, not just who is allowed to ask.

The depth that actually matters for regulated finance

Stack the requirements and a clear hierarchy appears. Semantics first: the model has to carry meaning, not just rows, or the agent cannot reason. Governance next: the model has to know its own rules, owners and controls, or the reasoning is ungrounded. Freshness third: the model has to be living, or the reasoning is confidently wrong. Sovereignty last but non-negotiable: the model has to keep sensitive context inside your control, or none of the above is safe to use.

Thin versus native is the opening move in that argument, not the whole game. For a bank or insurer in the EU, the real bar is semantics plus governance plus freshness plus sovereignty — all four. A connector that nails the first two and ignores the last two is a confident, well-spoken liability.

• Semantics — reason over a model, not a spreadsheet
• Governance — owners, controls and rules the model knows about
• Freshness — a living repository, not an aging snapshot
• Sovereignty — context that stays in the EU and under your control

What this means for ArchiLU — and where we are honest

We will say plainly what we do not have: ArchiLU does not ship an MCP server today. It is a conviction and a direction on our roadmap, not a feature you can switch on. We would rather be clear about that than market a product that does not exist.

What we do ship is the part that makes any future MCP worth having. A connected, governed EA model — capabilities, application portfolio, dependencies — that carries semantics rather than bare rows. Hosting in an EU region or on-premise that you control, so the context never has to leave your sovereignty perimeter. Native French and English, built around DORA and CSSF documentation needs. And published pricing you can read before you ever talk to sales. Build the context right, keep it living, keep it sovereign — then the protocol on top is a detail. The order is the point.

One honest caveat to keep in view: an EA model and an MCP help you document and prove your architecture; they do not make you compliant. Regulatory readiness is a documentation and evidence aid, not a legal guarantee — treat it that way.

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