The technical architect’s guide to connecting Sparx EA to Cursor and Claude Code

The short version: a developer working in Claude Code or Cursor can ask a question about your architecture — “what does the payment service integrate with?” — and get an answer from the live EA repository without leaving the editor. The bridge is EA GraphLink, a read-only MCP server that exposes the repository to any tool that speaks the Model Context Protocol. This is one of the newer paths in the AI Augmented Architecture stack, and it lands closer to the keyboard than most.

The piece the developer workflow has been missing

Most conversations about enterprise architecture and AI center on leadership: a stakeholder asks a question, gets context, decides faster. There is a quieter use case that rarely gets airtime — the engineer mid-build, deep in an IDE, who needs to know something about the architecture the code depends on.

The questions are concrete. What systems integrate with this API endpoint? What’s the approved protocol for outbound connections? Which other teams own services in this domain? The engineer needs the answer without leaving the editor, without breaking flow, and with confidence that it reflects the current state of the model.

Today the usual path is to message the architecture team, wait, lose the thread, and resume later. Or to guess, push ahead, and meet the constraint the hard way in code review. Either way the architecture model — the place that holds the answer — sits one tool and several minutes away from the person who needs it.

An MCP connection closes that gap. The engineer asks the question inside Cursor or Claude Code, the answer comes back from the live repository, and work continues. That single shortcut changes how delivery teams and architects deal with one another.

What MCP is, and why it changes the access pattern

The Model Context Protocol is an open standard for wiring AI tools to external data sources and services. EA GraphLink implements an MCP server on top of your Sparx EA repository, so any MCP-compatible client — Cursor, Claude Code, and a growing list of others — can query it through a uniform interface.

Instead of opening the Sparx EA desktop client or writing SQL against the database, the engineer types a plain-language question. GraphLink translates it into a structured query against the repository, returns the results, and the IDE’s AI model folds them into the working context. The payoff is continuity: a developer in TypeScript can drop a comment, // what services should this call integrate with?, and read the answer inline without a single tool switch.

How the connection is wired

The flow has three hops, end to end. The engineer’s question travels out of the IDE, through GraphLink, into the repository, and the answer retraces the path.

Three things have to be in place:

1. GraphLink running against your repository. GraphLink is the bridge that makes the repository queryable over MCP. It needs network access to your EA database, which in practice means running it inside your network boundary or behind a secure tunnel. It also needs an MDG Technology defined for your repository — that is what translates the physical Sparx schema into the GraphQL schema the MCP server exposes. Without it, the model’s structure is invisible to the query layer.

2. The MCP server registered in the IDE. Cursor supports MCP servers through its settings; you point it at your GraphLink instance and authenticate (GraphLink uses API-key authentication by default). Claude Code is configured the same way, by adding the server to your installation.

3. Scope and permissions decided. GraphLink offers fine-grained control: restrict queries to specific packages, exclude sensitive areas of the model, or cap query complexity. This is what keeps a developer from reaching — by accident or on purpose — into confidential architecture.

Once configured, a question typed in the IDE — as a comment, in a chat panel, or in a prompt — is handled by the MCP server and answered in a few seconds. That round trip is quick enough to keep flow intact for most queries.

Which questions land well — and which don’t

MCP shines on specific, factual lookups against the model.

“What systems does our payment gateway integrate with?” works. The question is precise, it resolves to a discrete set of elements, and the engineer can act on the answer at once. So does “what’s the approved API contract for service-to-service communication?” — especially when that contract lives in a Sparx connector or a requirement artifact tied to the architecture. “Which teams own services in the customer-facing domain?”, “what data flows through our ELT pipeline?”, “show me the components of the order-fulfillment system” — all return clean, usable answers.

What lands poorly is anything that calls for judgment rather than retrieval. “How should we integrate with this service?” depends on context, constraints, and tradeoffs, and that is an architect’s conversation. MCP is a query interface, not a design tool. The dividing line is simple: if the answer already exists in the model, the connection finds it; if the answer requires interpretation, a person still has to supply it.

The governance question you have to answer first

Giving developers a direct line into the EA repository raises a fair question: what should they see, and who watches?

The answer follows your governance model. Some organizations treat architecture as largely open — developers ought to know how systems connect and what the landscape looks like — and reserve restrictions for genuinely sensitive material: security detail, infrastructure specifics, business-confidential design decisions. Others run a tighter model, where a team sees its own domain but not its neighbors’, and architects mediate cross-domain integration questions.

GraphLink’s permission model supports both. Log every query and keep it auditable without blocking anything; or make specific elements, relationships, and packages unqueryable outright; or require authentication and record which developer asked what. The decision that matters is making the policy explicit before you switch it on. “Developers can query the architecture repository” should not surprise your security team or your architects — it should be a deliberate choice with clear governance behind it.

In practice, read-only access turns out to be lower-risk than it first sounds. The repository is the system of record. If developers are reading from it, the worst case is acting on stale data — and that is a model-maintenance problem, not one MCP creates. Treat it as an access pattern, not a security hole: your security posture for the repository should hold whether someone reaches it through the desktop client or through an IDE.

How this resets the architect–engineer relationship

When engineers can pull architecture facts directly, the architect’s role shifts. Instead of being the gatekeeper of information, the architect becomes the keeper of the source of truth and the interpreter of decisions that need judgment — design questions, integration choices, governance. Less time goes to “what does the architecture say about X?” and more to “what should the architecture do about X?”

Both sides tend to come out ahead. Architects spend their hours on work that actually needs them; engineers get unblocked without queuing behind an intermediary; decisions move faster because the facts are available the moment they’re needed.

There is a condition baked into all of this: the model has to be current. When access runs through architects, staleness can hide — an architect might notice the model hasn’t been updated and add context from memory. Direct access removes that cushion. An engineer queries, gets an answer, and discovers it’s wrong because the data hasn’t been touched in a while. That exposure is healthy. It forces architecture-data currency to be taken seriously, and most teams that turn on MCP find they tighten their maintenance discipline as a result. That is a benefit, not a tax.

A configuration walkthrough

Here is the basic loop for an engineer using EA context in Cursor.

The engineer opens a file and adds a comment: // What API contracts does the payment service expose? They invoke the MCP tool through Cursor’s interface (typically Ctrl+K or Cmd+K). Cursor routes the question to the GraphLink MCP server. GraphLink parses it, converts the natural language into a structured query — this is where the model’s GraphQL schema earns its keep — executes it against the Sparx EA database, and returns the results.

What comes back might be a list of exposed APIs and their contracts, a view of what connects to the payment service, or documentation on integration requirements. Cursor surfaces it as context, either in a side panel or inserted into the file, depending on what was asked. The engineer now has what they need without leaving the editor, waiting on email, or switching context.

If something is wrong or incomplete, that is a data-quality signal worth reporting to the architecture team — and the fix is unambiguous: keep the model current, and the queries return correct answers.

When this is worth doing

MCP integration pays off at a particular level of maturity, and it rests on three readiness conditions.

A repository worth querying. If your model is mostly empty or patchy, MCP makes things worse, not better — engineers query it, get half-answers, and trust it less than if there were no access at all.

A conscious view of what to restrict. You don’t need flawless governance, but you do need to have thought through which information is open and which is held back.

A delivery organization mature enough to use the information well. Where architecture gets used to dodge decisions rather than inform them, MCP won’t fix the culture — it will just spread the problem faster.

Most established teams that have been building on Sparx EA for a while already clear all three bars, and for them the integration is quick to stand up and immediately useful. The value is sharpest in large organizations with many delivery teams and tangled integration points, where architecture information is the bottleneck — but even smaller teams feel the difference when context lives in the IDE instead of an inbox.

Start with a pilot

If you want to test this, start narrow: one delivery team, one use case. Pick a team in a well-defined domain where architecture facts clearly help. Stand up GraphLink and Cursor MCP for that team. Watch which questions they ask, what answers they actually need, and where the repository comes up thin or wrong.

Use that feedback to refine your governance model and to fill the gaps in your architecture data, then extend to the next team. The infrastructure is the easy part — once GraphLink is in place, wiring up a new IDE is usually under a day’s work. The real work is the conversation between architects and delivery teams about which information engineers should have at their fingertips and how it stays accurate. If you want help running that pilot and getting the integration right, talk to a practitioner or explore the wider AI Power Tools ecosystem.