What Is the Sparx EA MCP Server? Technical Guide for AI Integration

The Model Context Protocol is an open standard that lets an AI assistant discover an external data source, understand what it contains, and query it in real time. Apply that to an EA repository and an assistant such as Claude or Microsoft Copilot can answer questions about your architecture directly from the model — which applications are end-of-life, what a capability depends on, which diagrams reference a given component — instead of working from a stale export. The catch is that the repository has to be exposed through an MCP server first, and Sparx does not provide one out of the box.

Two products, two MCP servers

As of mid-2026, two products give Sparx EA an MCP interface. They are not the same thing, and the difference matters more than the marketing suggests.

Put plainly: EA GraphLink is the shared, server-side, read-only window onto the repository; AI Power Tools is the local, hands-on workbench that can change the model. Most practices that are serious about AI Augmented Architecture end up running both, because they solve different problems. A deeper walkthrough of the local route lives in connecting Sparx EA to Cursor and Claude Code.

How the two paths fit together

Both servers read from the same underlying Sparx EA repository. What changes is where the server runs, who connects to it, and whether the assistant can write back.

What an MCP server exposes from the repository

Whichever product you use, the value depends on serving the model as structured, typed data rather than raw rows. A well-built EA MCP server makes the following available to a connected assistant:

Typed elements. Each element is returned as its modeled type — an ArchiMate Application Component, a Business Process, a Technology Node — not as a generic UML object with a stereotype string the assistant has to parse. That lets you ask for “all Application Components in Finance with lifecycle status End-of-Life” and get a clean, filtered list.

Relationships. Realisation, Serving, Assignment, Composition and the rest are queryable with their source and target, so an assistant can resolve “which components realize the Customer Onboarding capability?” from the actual relationship graph.

Tagged values. Custom attributes defined by your MDG extensions come through as structured dimensions. A governed Lifecycle Status enumeration (Active, Migrate, Eliminate, End-of-Life, Decommissioned) becomes a vocabulary the assistant can filter and count on precisely.

Package structure and documentation. The repository hierarchy is navigable, so queries can be scoped to a package, and element notes — including the Context, Decision and Consequences of an Architecture Decision Record — are readable for questions that need narrative context, not just attributes.

Diagram metadata. Diagram names and the elements that appear on them are exposed. The assistant reads what a diagram contains; with AI Power Tools it can also drive the EA UI to validate a diagram visually.

Why MDG governance decides the answer quality

This is the part most teams underestimate. The quality of the AI’s answers is bounded by the governance of the model. An MCP server serves the repository as it actually is. Where elements are correctly stereotyped and tagged values follow a governed enumeration, the assistant receives precise, typed data and returns precise answers. Where the model is a pile of generic UML elements with ad-hoc notes — someone typed “EOL” instead of “End-of-Life,” or recorded lifecycle status as free text — the assistant inherits that mess.

Ask a well-governed repository “how many applications are in End-of-Life status?” and you get a number and a list. Ask the same of a repository where that fact lives in scattered free-text notes and the answer is unreliable, because there is nothing structured to query. This is exactly why we treat MDG Technology governance as a prerequisite, not an afterthought — the same argument runs through MDG Technology as your AI quality gate. EA GraphLink’s reliance on an MDG-defined GraphQL schema makes this explicit: no governance, no usable schema.

Which AI tools can connect

Because MCP is an open standard, an EA MCP server is vendor-neutral. The clients teams connect most often in 2026 include:

• Anthropic Claude — Claude apps and API integrations, including Claude Code for architects building automation.
• Microsoft Copilot — Microsoft 365 Copilot and Copilot Studio.
• Salesforce Agentforce, Google Gemini, and OpenAI ChatGPT Enterprise — each with MCP client support.
• Cursor and custom Azure OpenAI applications — useful for architects working close to the model.

New MCP-compatible tools can connect without changes to the server configuration. For the read-only enterprise path, EA GraphLink also exposes a GraphQL interface for BI tools such as Power BI and Tableau, so the same governed model feeds both your AI assistants and your dashboards.

Licensing and who does the work

Both products are licensed from their vendors, separately from your Sparx EA modeling licenses, and the AI assistants that query them are not Sparx EA users — they do not consume modeling seats. Sparx Services helps you choose between the server-side and local paths (or run both), coordinate licensing, stand up Pro Cloud Server where EA GraphLink needs it, define or harden the MDG Technology that governs answer quality, register your AI clients, and validate the first real queries. That work is described in full on AI Power Tools and AI Augmented Architecture.

Frequently asked questions