EA GraphLink’s MCP Server connects Sparx EA to any AI tool that implements the Model Context Protocol: Microsoft Copilot, Salesforce Agentforce, Claude, Google Gemini, ChatGPT Enterprise, Azure OpenAI, Cursor, and more: from a single deployment.
MCP (the Model Context Protocol) is an open standard for connecting AI tools to data sources. It defines a common interface: a server exposes data through MCP; a client (the AI tool) connects to it and can query that data. EA GraphLink implements an MCP Server that exposes your Sparx EA repository. Any MCP-compatible AI tool can then query the repository in natural language.
The critical implication: you don’t choose between AI tools at the infrastructure level. One EA GraphLink deployment supports multiple simultaneous MCP connections. Copilot for M365 users, Agentforce for Salesforce users, Claude for architects doing deep analysis: all connecting to the same repository, from the same EA GraphLink MCP Server.
This is not marketing language for a proprietary integration approach. MCP is a documented open standard. EA GraphLink’s implementation of it is the same technical protocol used by every MCP-compatible tool. Organizations are not locked into any AI vendor or ecosystem by adopting this approach.
What MCP enables:
What MCP doesn’t replace:
| Tool | Organization Type | Primary User | Data Stays in Environment? |
|---|---|---|---|
| Microsoft Copilot | Microsoft-centric (M365) | Business Stakeholder | No: Copilot cloud |
| Microsoft Fabric | Microsoft-centric (Azure data estate) | Data Architect | Yes: Azure tenant |
| Salesforce Agentforce | Salesforce-centric | Business Stakeholder | No: Agentforce cloud |
| MuleSoft Fabric | Salesforce-centric (MuleSoft integration estate) | Integration Architect | Yes: MuleSoft infrastructure |
| Claude | Universal | EA Architect, Arch Manager | No: Anthropic API |
| Google Gemini | Google Workspace | Business Stakeholder | No: Google cloud |
| ChatGPT Enterprise | OpenAI-standardized | EA Architect | No: OpenAI API |
| Azure OpenAI | Regulated industries, any organization in Azure | Any user (regulated context) | Yes: Azure tenant |
| Cursor / Claude Code | Universal (developer context) | Systems Engineer, Technical Architect | No: Anthropic API |
| Kernaro AI Hub | Universal | Business Stakeholder | Configurable |
Note: Power BI and Tableau use EA GraphLink’s GraphQL API, not the MCP Server. Kernaro Assist uses an in-EA extension mechanism. The AI Modeling Workbench is a native EA client feature. None of these three are MCP integrations.
For business stakeholders (executives, program managers, compliance officers, business unit leaders who don’t use EA):
The relevant MCP integrations are those that surface architecture data within the platforms where these stakeholders already spend their time.
The common characteristic: stakeholders don’t need EA access, EA skills, or any new tools. Architecture data comes to them.
For enterprise architects and modeling architects (users who work in EA directly):
The primary in-EA AI option is Kernaro Assist: but this is not an MCP integration. It’s an in-EA extension that provides AI assistance during modeling work, within the EA client. See the Kernaro Assist guide for this use case.
For AI-assisted analysis and documentation outside the EA client, architects can use Claude via MCP: connecting through a Claude desktop or API interface to query the repository for deep analysis tasks, documentation synthesis, and complex reasoning.
For technical architects and systems engineers (users who work in code environments):
These integrations are particularly valuable for organizations where the boundary between architecture and engineering work is fluid: where technical architects regularly move between EA models and code.
For data architects and integration architects:
For regulated industry contexts (where data must stay within a controlled environment):
Every MCP integration in this list depends on EA GraphLink, and EA GraphLink depends on your MDG Technology definition.
EA GraphLink transforms the physical Sparx EA repository schema using your MDG definition to create the queryable knowledge graph that MCP clients access. The MDG definition determines what element types exist, what stereotypes are applied, what tagged values are captured, and how relationships are structured. EA GraphLink uses this definition to make sense of your repository schema.
If your MDG governance is strong: stereotypes consistently applied, tagged values reliably populated, relationships accurately maintained: EA GraphLink produces a high-quality knowledge graph. AI tools querying it return accurate, useful answers.
If your MDG governance is weak: stereotypes inconsistent, tagged values sparse, relationships poorly maintained: EA GraphLink produces a degraded knowledge graph. AI tools querying it return incomplete or unreliable answers. This is not a failure of the AI or of EA GraphLink. It is a reflection of repository governance quality.
No MCP integration: regardless of which AI tool: overcomes poor MDG governance. The assessment of MDG readiness before integration deployment is not optional formality; it determines whether the integration will produce value or produce embarrassment.
Discover assesses MDG readiness. If your organization’s MDG governance maturity is uncertain, Discover is the correct first step before any MCP integration planning.
EA GraphLink exposes two interfaces. Understanding the distinction clarifies which integrations belong to which category.
MCP Server:
GraphQL API:
Both interfaces draw from the same EA repository, via the same EA GraphLink knowledge graph. They serve different consumption patterns. Most organizations benefit from both: GraphQL for BI dashboards (structured visualization for a wide audience), MCP for AI assistant access (natural language queries for on-demand questions).
The choice between interfaces isn’t exclusive: one EA GraphLink deployment supports both simultaneously.
What is the Model Context Protocol (MCP)?
MCP is an open standard, originally developed by Anthropic and subsequently adopted broadly across the AI industry, that defines how AI tools connect to external data sources. It works as a client-server protocol: a server exposes data via MCP (in this case, EA GraphLink), and MCP clients (AI tools) connect to query it. Because MCP is an open standard: not a proprietary protocol: any tool that implements it can connect to any MCP server, regardless of vendor. This is what allows EA GraphLink’s single MCP Server to support Copilot (Microsoft), Agentforce (Salesforce), Claude (Anthropic), and Gemini (Google) simultaneously.
Does EA GraphLink implement the standard MCP specification?
Yes. EA GraphLink’s MCP Server implements the standard MCP specification. It is not a proprietary or modified version of MCP. Any MCP-compatible tool should be able to connect to it. This is the basis of the “one deployment, every AI tool” claim: it’s not a marketing promise; it’s a consequence of implementing an open standard.
Do I need a separate EA GraphLink deployment for each AI tool I want to connect?
No. EA GraphLink’s MCP Server supports multiple simultaneous client connections. One deployment can support Copilot, Agentforce, Claude, and Gemini connections simultaneously. This is one of EA GraphLink’s key architectural advantages: the infrastructure investment is made once, and additional integrations are configuration additions, not new deployments.
Can I connect to MCP-compatible tools that aren’t on this list?
Yes, in principle. Because EA GraphLink implements the standard MCP specification, any MCP-compatible tool should be able to connect. As the MCP ecosystem expands: new AI tools, new platforms, new enterprise software implementing MCP: they can connect to your existing EA GraphLink deployment without infrastructure changes. The list of tools above reflects the current ecosystem as of the time of this guide; it will expand over time.
Is MCP the same as an API?
Not exactly. Both MCP and a traditional API enable software systems to communicate. The distinction is purpose and interface style. A traditional REST API or GraphQL API returns structured data in response to structured queries: the client must know the schema and query format. MCP is designed for AI tools specifically: it allows AI tools to discover what data is available, understand its structure, and query it in ways that work well with natural language processing. MCP is purpose-built for the AI integration use case; GraphQL is purpose-built for structured data consumption. Both are used by EA GraphLink for different integration types.
What is the difference between the MCP server and the GraphQL API in EA GraphLink?
Both expose the same underlying EA repository data, transformed by EA GraphLink. The difference is who consumes them and how. The GraphQL API is consumed by BI platforms (Power BI, Tableau) that need structured datasets for visualization. The MCP Server is consumed by AI tools (Copilot, Claude, Agentforce, Gemini) that need to answer natural language queries. The data source is the same; the interface is different because the consumption pattern is different. GraphQL returns structured data for rendering charts and tables; MCP returns information for AI tools to reason about and surface as natural language responses.
EA GraphLink Foundation is the starting point for every MCP integration. Before any AI tool can connect, EA GraphLink must be deployed and configured. The EA GraphLink guide covers prerequisites, deployment requirements, and the role of MDG governance.
If your MDG readiness is uncertain: Discover assesses your repository governance and determines whether it’s ready for AI integration.
If you’re ready to deploy a specific integration: Connect is the engagement that takes you from EA GraphLink Foundation to one or more live integrations.
For side-by-side comparison of all integrations: Integration Comparison
[Start Your Connect Engagement]
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.