Why the Catio MCP

Catio does not replace your coding IDE. It defines what your coding IDE executes. The MCP is the connection between the two.

Two planes

Catio's model runs on two planes:

• The control plane is Catio, the Architecture IDE. Requirements land here. Context is encoded here. Blueprints are generated, refined, committed, and governed here. This is the system of record for architecture intent.
• The execution plane is your coding IDE — Claude Code, Cursor, VSCode, Windsurf, Zed, and anything else that speaks MCP. This is the system of record for code.

The MCP is the interface between them. Committed Designs and workspace context flow down into the coding session; implementation reality and design edits flow back up into Catio. Without it, the two planes meet only through copy-paste.

What the connection gives you

• Queries against the live model. get_workspace_info, get_inventory_summary, search_inventory_components, and search_inventory_relationships answer questions about components, dependencies, and topology from the model Stacks maintains, without leaving the editor.
• Context as a retrievable object. get_workspace_context returns the workspace's requirements, company profile, and architecture context. search_context searches indexed policies, uploaded documents, and questionnaire answers and returns passages with resolvable citations. The constraints a change has to satisfy are available to the agent writing the code.
• Deliberation with decision history attached. ask_archie runs the same workspace-grounded reasoning available in the app, so an open trade-off can be checked against decisions already recorded rather than re-argued.
• Committed specs, pulled and amended in place. search_recommendations and get_recommendation retrieve the Blueprint behind the ticket so code is generated against its spec. When implementation surfaces something the spec missed, edit_blueprint_with_archie and update_blueprint amend it in Catio, where it is governed, rather than leaving it to drift.

For the full tool surface and required parameters, see Tools.

The failure mode it removes

The boundary between deciding and building is where architecture intent is usually lost. A Design is committed in Catio, a ticket is written from it, and the developer builds from the ticket prose. The spec is re-inferred downstream, and the deviation surfaces in review, or later, as rework.

Pulling the committed spec through the MCP closes that gap. What ships is then measurable against a design that was written down, which is the precondition for exception-based review: architects review deviations rather than reviewing every change. The Architecture-Led AI SDLC is that motion end to end.

What the MCP does not do

The MCP does not write your code, and Catio stops at operational execution — pipelines, testing, and deployment stay yours. For the boundaries of the MCP itself, see Limitations.

Where to go next

• MCP Setup — connect your client.
• Tools — every tool the MCP exposes.
• Prompting — how to ask well.
• Query Your Architecture and Find Blueprints with the Catio MCP — a worked read-only session.
• Generating Architecture-Aware Code with Catio MCP — requirement through to pull request.