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, can connect to an MCP server and query it the same way. Which assistant a given EA server supports is the product’s call, and the sections below say which is which.

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 an AI assistant: “Which applications support our supply chain capabilities?”
2. The assistant, acting as the MCP client, recognizes this as something an EA MCP server can answer.
3. The assistant 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. The assistant 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.

How MCP differs from function calling and plugins

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. The AI tools for Sparx EA comparison puts them beside the other options.

The MCP server in Kernaro AI Hub. This is a read-only MCP server from Sparx Systems, 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 Sparx EA. This is free, published by NovoCircle, and runs a local MCP server on the architect’s own machine. It has full read and write access to the repository and can validate diagrams visually through the EA user interface. For Claude, the Claude Desktop extension is the MCP server and a plugin adds the library of skills; a separate VS Code extension gives GitHub Copilot the same MCP server, and VS Code loads the same skills. It is Windows only, with Enterprise Architect on the same machine. 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 is on the AI Power Tools for Sparx 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

Kernaro AI Hub’s MCP server serves data through a GraphQL layer that is MDG-aware, and AI Power Tools works inside your MDG too. 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.

The connection is the easy part. Deciding what the model has to hold, and when it is complete enough that people can trust the answers, is the work that pays off, and it belongs to the architect. 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 (Microsoft 365 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, a new MCP-compatible tool can be pointed at it with configuration rather than new integration code.

For Sparx EA specifically, the current picture is narrower. AI Power Tools works with Claude (Claude Desktop chat and Claude Code in the Claude desktop app) and with GitHub Copilot in VS Code. Microsoft 365 Copilot has no live connection to it. Microsoft 365 Copilot answers questions, read-only, from a published Power BI semantic model built from your EA data. With Kernaro AI Hub, it can also reach your EA data through Hub’s read-only API, via Copilot Studio or a Microsoft 365 connector.

Why this matters for the job

Two jobs sit behind MCP for an EA team. One is getting the repository’s answers to the people who ask, so the portfolio question does not need an architect in the middle each time. The other is having AI do the modeling work in the tool and the model, which is how a team builds the diagrams for every application and keeps the mappings current. Today an architect does the lookups and the drawing by hand, and both are slow and go stale. MCP is one way an assistant reaches the repository to do either job. Reporting to Power BI, Microsoft 365 Copilot, Fabric or a warehouse uses other connections, covered on the reporting page, and the mechanics are in the NovoCircle documentation (opens in a new tab).

The skill that stays with the architect is stating the intent and the standard. That means deciding which questions the business should be able to ask, what the assistant may read and what it may change, and what a complete model looks like. An assistant is only as good as the person prompting it, and the governance work below is what makes its answers worth acting on. Before MCP, EA repositories were effectively invisible to AI, and most EA teams had no engineering capacity to build a custom integration 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 can get an architecture answer in the AI assistant they already use, without opening a separate portal. A project team can get application-dependency answers while planning a workstream. Operations teams can get infrastructure-coverage answers inside the tools they already live in, where those tools support MCP.

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