Architecture answers in the engineer’s editor: Sparx EA, Kernaro AI Hub and MCP

Part of a technical architect’s job is answering delivery engineers. What does the payment service integrate with? Which protocol is approved for outbound connections? Who owns the services in this domain? The answers are in the EA repository, and the engineer is in an editor. This article is about putting those answers in the editor, through the read-only MCP server in Kernaro AI Hub, and about what the architect has to decide and maintain so the answers can be trusted.

How engineers get architecture answers today

An engineer mid-build needs to know something about the architecture the code depends on. Usually they message the architecture team, wait, lose the thread and come back to it later. Or they guess, push ahead, and meet the constraint in code review. The architecture model holds the answer, but it sits one tool and several messages away from the person who needs it. The architect, meanwhile, spends part of every week relaying facts that are already written down.

How it works AI-augmented

With the repository reachable over the Model Context Protocol, the engineer types the question in plain language where they are working. The AI in the editor turns it into a query, the Hub’s MCP server runs it against the repository, and the answer comes back into the editor. The engineer keeps working, and the architect stops relaying facts.

Kernaro AI Hub is a Sparx Systems web product, and its MCP server is read-only. It answers questions and does not change the model. It runs on a server and serves the whole enterprise, which is what you want when several delivery teams query the same source of truth. Sparx EA itself has no native MCP server, so the Hub is the route for shared access. The Hub reads the repository through the structure your MDG Technology defines, so a model without a clear modeling language is hard for it to query well.

Whether a particular editor can use the Hub’s server depends on that editor. If your engineers’ AI coding tool can call a remote MCP server, it can be pointed at the Hub, authenticated the way your Hub deployment requires. Check the editor’s own documentation and your Hub deployment before you plan a rollout around it.

What it asks of the technical architect

Deciding what engineers can see

Giving developers a direct line into the repository raises a fair question: what should they see, and who watches? Some organizations treat most architecture as open, so engineers know how systems connect, and restrict only sensitive material such as security detail, infrastructure specifics and confidential design decisions. Others let a team see its own domain but not its neighbors’, and keep cross-domain integration questions with the architects. Sparx Systems describes Kernaro AI Hub as providing centralized permissions and audit, and that is where either policy is set. Confirm with Sparx how package-level scoping works in your deployment.

The skill here is making the policy explicit before anyone switches the connection on. Engineers querying the repository should not surprise your security team or your architects. Read-only access carries less risk than it first sounds, because the worst case is an engineer acting on stale data, and stale data is a model-maintenance problem that exists with or without the connection. Your security posture for the repository should hold whether someone reaches it through the EA client or through an editor.

Knowing which questions the model can answer

Specific, factual lookups work well. “What systems does our payment gateway integrate with?” resolves to a discrete set of elements, and the engineer can act on the answer at once. “What is the approved API contract for service-to-service communication?” works when that contract is held in the model as a connector or a requirement. “Which teams own services in the customer-facing domain?” works when ownership is recorded.

Questions that need judgment do not. “How should we integrate with this service?” depends on context, constraints and tradeoffs, and that is a conversation with an architect. If the answer is already in the model, the connection finds it. If the answer needs interpretation, a person supplies it. The architect’s skill is telling delivery teams where that line sits, so they bring the second kind of question to a person.

Keeping the model current

When answers run through an architect, staleness can hide, because the architect notices an out-of-date element and adds context from memory. Direct access removes that cushion. An engineer gets an answer, acts on it, and finds out later it was wrong because nobody updated the model. The connection makes model currency visible, and the architect has to treat it as part of the job. A thin or patchy model makes things worse here: engineers get half-answers and trust the repository less than before. Where an answer turns out wrong or incomplete, the engineer should report it to the architecture team as a data-quality issue, and the fix is in the model.

How the architect’s work changes

When engineers can pull architecture facts directly, the architect spends less time on what the architecture says about something and more time on what the architecture should do about it. They keep the source of truth current and interpret the decisions that need judgment: design questions, integration choices and governance. Engineers get unblocked without waiting on an intermediary.

When an architect needs to change the model, not read it

Everything above is read-only access for delivery teams. A technical architect who works in a coding environment and needs to build or correct model content has a different route: AI Power Tools for Sparx EA, free for every Sparx user and published by NovoCircle. It runs on the architect’s own Windows machine with Enterprise Architect installed, and it acts under the architect’s own EA login. Its documented clients are the Claude desktop app (Claude Desktop chat and Claude Code) and GitHub Copilot in VS Code on Windows. It is local to that machine, so it is not a shared endpoint for a delivery team. Cursor is not a documented surface for it. Our piece on working on Sparx EA from your coding environment covers that job.

Starting small

Start with one delivery team in a well-defined domain where architecture facts clearly help. Agree the access policy, connect that team’s editors to the Hub’s MCP server, and watch which questions they ask and where the repository comes up thin or wrong. Use what you learn to fill the gaps in the model and refine the policy, then extend to the next team. Once the server is in place, adding another editor is a configuration task. The harder work is the conversation between architects and delivery teams about which information engineers should have and how it stays accurate. The comparison of AI options for Sparx EA sets the routes side by side.