What Is the Model Context Protocol (MCP)? A Complete Guide for Enterprise Architecture Teams

In one line: the Model Context Protocol (MCP) is an open standard — published by Anthropic in November 2024 and now backed by most major AI vendors — that lets any compatible AI assistant query any data source through one shared interface, instead of a custom connector per tool.

For enterprise architecture teams, that single shift is what turns a Sparx EA repository from a system nobody outside the EA team can reach into a governed context source the whole organization’s AI can draw on. Any MCP-compatible assistant — Claude, Microsoft Copilot, Google Gemini, Salesforce Agentforce, ChatGPT Enterprise — connects to an MCP server and queries it the same way.

This guide explains what MCP is, how the architecture works, how it differs from older integration patterns, and what it specifically changes for teams running AI Augmented Architecture on Sparx EA.

Where MCP came from, and the problem it solves

Anthropic published the Model Context Protocol specification in November 2024 as an open standard. The reasoning was simple: a large language model is only as useful as the context it can reach. With no access to current, relevant data, an assistant answers from training data — which may be stale, wrong, or far too general for an enterprise question.

Until then, wiring an AI assistant to a data source meant building a different integration for every tool. A connector built for Claude did not work with Copilot. A connector for Copilot did not work with Gemini. Each vendor had its own API format, authentication model, and way of describing what it could do. Anthropic called this the N×M problem: every one of your data sources times every one of your AI tools became a custom build to write and maintain.

MCP collapses that grid into a single standard. If a data source speaks MCP and an assistant speaks MCP, they interoperate without bespoke code. The protocol handles discovery, capability description, authentication, and queries in a consistent way. Adoption moved fast: through 2025, Microsoft, Google, Salesforce, OpenAI, and a long list of enterprise software vendors lined up behind MCP, and it became the de facto standard for connecting AI to live data.

How the MCP architecture works

MCP has three parts.

The MCP server exposes data sources and tools to AI assistants. It declares what it offers, answers standardized discovery requests, handles queries, returns structured results, and manages its own authentication and access controls.

The MCP client is the AI assistant, or the orchestration layer behind it. It discovers the servers it has been pointed at, understands what each one offers without custom code, decides when a question warrants querying a server, and folds the response into its answer.

The MCP protocol is the communication layer in between — the handshake that governs discovery, capability declarations, query formats, and response structures so client and server interoperate regardless of who built them.

For an architecture question, the flow looks like this:

1. A user asks Copilot: “Which applications support our supply chain capabilities?”
2. Copilot, acting as the MCP client, recognizes this as something an EA MCP server can answer.
3. Copilot sends a standardized MCP query to that server.
4. The server reads the relevant elements and relationships from the Sparx EA repository.
5. It returns the matching elements and relationships in a structured form.
6. Copilot turns that into a natural-language answer and presents it to the user.

How MCP differs from function calling and plugins

MCP is not the first attempt to give AI assistants reach into outside systems. It is a step up from the two patterns that came before it. The table below sets them side by side.

Dimension	Function calling / tool use	AI plugins	MCP
How capabilities are exposed	Each function defined by hand in the assistant’s configuration	Each plugin custom-built and registered with one assistant’s framework	Server declares its capabilities; the client discovers them dynamically
Adding a new capability	Write a new function definition, per assistant	Build and register a new plugin, per assistant	Server exposes it once; every connected client can use it
Portability across AI vendors	None — per-AI, per-function effort	None — tied to one vendor’s plugin system	One server works with Claude, Copilot, Gemini, and Agentforce at once
What it can expose	Functions (actions) only	API calls behind a plugin wrapper	Resources to read, tools to invoke, and reusable prompt templates

The headline difference is discovery. With function calling and plugins, every capability has to be spelled out in advance for every assistant. With MCP, the client asks the server what it can do and works it out at run time — which is exactly the behavior you want when the “caller” is an AI reasoning about a conversation rather than an application calling known endpoints.

Two ways to put MCP in front of Sparx EA

This is where the detail matters for EA teams, because there is no MCP server built into Sparx EA core. Two separate products, both new in 2026, give a Sparx EA repository an MCP interface — and they are built for different jobs.

EA GraphLink, part of Kernaro AI Hub. This is a read-only MCP server deployed on a server for enterprise-wide access. It depends on an MDG Technology defined for the repository, which translates the physical Sparx schema into a GraphQL schema that is then exposed through MCP. It is the right fit when many people and many assistants across the business need to query the same governed architecture data.

AI Power Tools for EA. This runs a local MCP server on the architect’s own machine alongside a skill library. It has full read and write access to the repository and can validate diagrams visually through the EA user interface. It is the right fit when an individual architect wants an assistant that can not only read the model but build and correct it — the full picture of what that local server exposes is on the AI Power Tools for EA page.

Whichever you deploy, what the MCP server can surface from the repository is the same kind of thing:

• Elements by type — ArchiMate types such as Business Process, Application Component, Technology Node, and Capability, queryable as first-class typed objects rather than generic records.
• Relationships — which applications realize which capabilities, which capabilities are used by which processes, which nodes host which artifacts.
• Tagged values — the governance attributes on each element: owner, lifecycle status, business domain, technology tier, health rating, and any custom attributes from your MDG extensions.
• Diagrams and views — names and metadata, not rendered images; assistants receive data, not pictures.
• Documentation — the element notes and description fields stored in the repository.
• Package structure — the organizational hierarchy that tells the AI which elements belong to which domains and sub-domains.

Why MDG Technology is the real quality gate

An MCP server in front of Sparx EA serves data through a semantic layer that is MDG-aware. That means an ArchiMate Application Component is queryable as “Application Component” — not as a generic UML Class with a stereotype that an AI has to parse and guess at. Your own custom stereotypes (say SaaS Application, Core Platform, Strategic Initiative) become first-class dimensions to filter on, and governed tagged-value enumerations (a Lifecycle Status of Active, End of Life, or Decommissioned) become structured fields the AI can group and filter by.

The consequence is direct. If elements use the correct MDG stereotypes consistently, the AI receives precise, semantically rich data and gives precise answers. If the repository is inconsistently typed — generic UML classes where ArchiMate elements belong, ad-hoc tags where governed extensions belong — the AI receives muddy data and answers in kind.

The quality of your EA repository governance sets the ceiling on the quality of the architecture intelligence MCP can serve. It is not a technical constraint; it is a governance one.

This is why we treat MDG governance design as a prerequisite or parallel workstream, not an afterthought, when we stand up an MCP integration. The plumbing is the easy part. Getting the model clean enough that the answers are trustworthy is the work that pays off. For the wider picture of how this reshapes the practice, see AI Augmented Architecture.

Which AI tools speak MCP

As of 2026, MCP-compatible assistants include Anthropic Claude, Microsoft Copilot (M365 Copilot and Copilot Studio), Google Gemini, Salesforce Agentforce, OpenAI ChatGPT Enterprise, the Cursor IDE, Azure OpenAI with an MCP client configured, and any assistant built on a framework that supports the protocol — including open-source LLM frameworks. The list keeps growing, and that is the quiet payoff: once an EA MCP server is deployed, each new MCP-compatible tool your organization adopts can reach the repository with no extra integration work.

What this changes for an EA practice

Before MCP, EA repositories were effectively invisible to AI. An assistant could not query your architecture data without a custom integration, and most EA teams had no engineering capacity to build and maintain one per tool. With MCP, the repository becomes a governed context source that any MCP-compatible AI in the business can draw on, and two things shift.

Architecture intelligence shows up where the work happens. An executive gets an architecture answer in Teams or Slack without opening a separate portal. A project team gets application-dependency answers inside Copilot while planning a workstream. Operations teams get infrastructure-coverage answers in the service-management tools they already live in.

Your governance work directly shapes AI output across the organization. The ownership assignments, lifecycle classifications, and architecture decisions the EA team maintains now feed answers used right across the business. The value of governance stops being an abstract argument and becomes visible in the quality of the responses people get.

Frequently asked questions