The missing piece in the developer workflow
Most discussions about enterprise architecture and AI focus on business stakeholders and architecture leaders. Someone asks a question, they get context, they make a decision faster.
But there’s a different use case that gets less attention. The systems engineer writing code in an IDE, in the middle of building a service, who needs to know something about the architecture that the code depends on.
They need to know: “What systems integrate with this API endpoint?” or “What’s the approved protocol for outbound connections?” or “What other teams own services in this domain?” They need this information without leaving their IDE and their flow state. And they need it to be current.
Today, that engineer messages the architecture team, waits for a response, breaks context, and resumes work. Or they make an assumption, proceed, and discover the architecture constraint later in code review.
EA GraphLink’s MCP server solves this. A systems engineer in Cursor or Claude Code can ask the architecture question directly within the IDE, get an answer from the live EA repository, and keep working.
This changes how delivery teams and architects interact with each other.
What MCP is and why it matters
MCP (Model Context Protocol) is a standard for connecting AI tools to external data sources and services. In this case, GraphLink implements an MCP server that connects your IDE-integrated AI tool (Cursor, Claude Code, or other MCP-compatible IDEs) to your EA repository.
Instead of using the Sparx EA GUI to query the repository, or writing SQL directly against the database, you ask a natural language question in your IDE and the MCP server translates it into a repository query, retrieves the results, and feeds them to Claude or another AI model running in your IDE.
The reason this matters is context preservation. A systems engineer working in TypeScript can type a question as a comment, “what services should this call integrate with?”, and get an answer without switching tools or mental context. The answer appears inline, in the IDE, formatted as code context or documentation.
This is the missing piece in how delivery teams currently access architecture information.
Connecting your repository to Cursor
The setup requires three pieces.
First, you need EA GraphLink installed and running against your Sparx EA repository. GraphLink is the bridge that makes your repository queryable via MCP. It requires network access to your EA database (typically this means running it inside your network boundary or via a secure tunnel).
Second, you install the GraphLink MCP server in Cursor. This is a simple configuration step, Cursor supports MCP servers through its settings. You point it to your GraphLink instance and authenticate (GraphLink uses API key authentication by default).
Third, you configure which parts of your repository the IDE tools can access. GraphLink supports fine-grained permissions: you can restrict queries to specific packages, exclude sensitive architecture information, or limit query complexity. This prevents developers from accidentally (or deliberately) querying confidential architecture data.
Once configured, when a developer types a question in Cursor, either as a comment, in a chat panel, or in a prompt, the MCP server handles the query and returns results. Claude Code works similarly, with MCP server configuration in your installation.
The connection is synchronous, a query takes a few seconds to traverse the repository and return results. This is fast enough to preserve flow state for most use cases.
What kinds of queries work well
MCP works best for specific, factual questions about your architecture.
“What systems does our payment gateway integrate with?” works well. The query is specific, it returns a discrete set of elements, and a systems engineer can act on the answer immediately.
“What’s the approved API contract for service-to-service communication?” works well, especially if the answer is documented in a Sparx connector or requirement artifact linked to the architecture.
“Which teams own services in the customer-facing domain?” works well. “What data flows through our ELT pipeline?” works well. “Show me the components of the order fulfillment system” works well.
What doesn’t work as well: questions that require architectural judgment rather than factual lookup. “How should we integrate with this service?” requires understanding context, constraints, and tradeoffs. An architect needs to engage. MCP is a query interface, not a design tool.
The line is: questions where the answer is discoverable in your architecture model work well. Questions where the answer requires interpretation or judgment don’t.
The governance question
Giving developers direct access to the EA repository raises a legitimate question: what should they be allowed to see, and should there be oversight?
The answer depends on your organization’s governance model. Some organizations treat architecture as mostly open information, developers should know how systems connect and what the technology landscape looks like. They restrict access primarily to sensitive information (security details, infrastructure specifics, business-confidential design decisions).
Other organizations maintain more restricted models: developers see the architecture for their domain, but not others. They want architects to mediate cross-domain integration questions.
GraphLink’s permission model supports both approaches. You can configure it so that every query is logged and auditable, but queries aren’t blocked. Or you can restrict specific elements, relationships, or packages from being queryable at all. Or you can require authentication and track which developer asked what.
The important thing is to decide your policy before implementing. “Developers can access the architecture repository” shouldn’t surprise your security team or your architects. It should be an explicit decision with clear governance.
Most organizations find that read-only access to the architecture repository is lower-risk than it initially sounds. The repository is your system of record. If developers are adding false information to it, that’s a data quality problem that MCP doesn’t create, it exists whether or not the repository is accessible via IDE. If they’re querying it and making decisions based on outdated information, that’s an MDG governance problem (which the previous article addresses).
MCP isn’t a security risk. It’s an access pattern. Your security model for the repository should stand independent of whether the access happens via the GUI or via an IDE.
How this changes the architect-engineer relationship
When systems engineers can access architecture information directly, the nature of architect involvement changes.
Instead of being the gatekeeper of information, architects become the maintainer of the source of truth and the interpreter of decisions that require judgment. They focus on design questions, integration decisions, and governance, the work that actually requires their expertise. They spend less time answering “what does the architecture say about X?” questions and more time answering “what should the architecture do about X?” questions.
This tends to improve both roles. Architects engage on the work that requires their expertise. Engineers get unblocked without waiting for an intermediary. Decisions happen faster because the information is available immediately.
There’s a requirement embedded in this: your architecture information has to be current and accurate. When access is mediated through architects, staleness is hidden, the architect might notice the repository hasn’t been updated and offer context. When access is direct, staleness becomes visible immediately. An engineer queries the repository, gets an answer, and discovers it’s wrong because the data is six months old.
This is actually good discipline. It forces you to take architecture data currency seriously. Most organizations that implement MCP discover they need to tighten up their model maintenance practices. That’s a benefit, not a cost.
A configuration walkthrough
Here’s the basic flow for a systems engineer using EA context in Cursor.
The engineer opens a file in Cursor. They add a comment: // What API contracts does the payment service expose? They invoke the MCP tool through Cursor’s interface (usually Ctrl+K or Cmd+K depending on setup).
Cursor routes the question to the GraphLink MCP server. GraphLink receives the request, parses the question, translates it to a repository query (this is where the AI understanding matters, converting natural language to structured query), executes it against the Sparx EA database, and returns the results.
The results might be a list of exposed APIs with their contracts, a diagram showing what connects to the payment service, or documentation about integration requirements. Cursor presents this as context, either in a panel, or inserted into the file, depending on what the engineer asks for.
The engineer now has the information they need without leaving Cursor, without waiting for email, without context switching.
If the information is wrong or incomplete, that’s a data quality issue. The engineer can report it to the architecture team. But the path to having correct information is clear: keep the architecture model current, and queries will return correct answers.
When to implement this
MCP integration makes sense at a particular maturity level.
You need a Sparx EA repository that’s mature enough to be useful. If your repository is mostly empty or spotty, adding MCP won’t help, engineers will query it and get incomplete answers, which is worse than not having access.
You need a governance model that’s conscious of what information should be restricted. You don’t need perfect governance, but you need to have thought about it.
You need a delivery organization that’s experienced enough to use architecture information responsibly. Early-stage teams sometimes use architecture as a way to avoid rather than help decisions. If that’s your culture, MCP won’t improve it, it will just propagate the problem faster.
Most mid-stage organizations that have been building on Sparx EA for 12+ months have all three. For those organizations, MCP is straightforward to implement and immediately valuable.
The value is most obvious in large organizations with multiple delivery teams and complex integration points, where architecture information is currently a bottleneck. But even in smaller organizations, the flow benefit of having context in the IDE is substantial.
Start with a pilot
If you’re interested in testing this, start with one delivery team and one use case.
Pick a team that works in a well-defined domain where architecture information is likely to be valuable. Set up GraphLink and Cursor MCP for that team. Monitor which questions they ask, what answers they need, and what information is missing or inaccurate from the repository.
Use that feedback to refine your governance model and improve your architecture data. Then expand to the next team.
The infrastructure is straightforward. The discipline is figuring out which architecture information engineers should have immediate access to, and ensuring that information stays accurate. That’s a conversation between your architects and your delivery teams, not a technical problem.
Once you’ve had that conversation, the technical integration is usually less than a day of work.
