MCP architecture server
Humans get the interactive chart room. Agents get navo-mcp — the hatch that serves the same ArchitectureMap YAML over Model Context Protocol. List maps, load topology, walk paths, and validate drafts without inventing services that do not exist in Git.
Out of the box, navo-mcp enables four safe toolsets. context reports server identity and workspace bearings. maps lists catalogs, summaries, full documents, and search across titles, tags, and node labels. graph returns nodes, edges, groups, and shortest paths between components. validate runs schema and integrity checks on a stored map or inline YAML before you trust a draft.
Typical agent calls include list_maps, get_map_summary, get_map, search_maps, get_node, list_nodes, get_edges, find_path, list_groups, validate_map, and validate_yaml — plus get_server_info and get_workspace_context for host diagnostics. Results are structured JSON with size caps so context windows stay honest.
Hosts can pin navo:// resources: navo://maps for the catalog, navo://maps/{id} for a single ArchitectureMap, and schema URIs for categories and architecture shape. Workflow prompts (for example architecture_onboarding, explain_data_flow, and sme_review_node) guide multi-step reviews without inventing nodes or edges that tools did not return.
Mutating work is open ocean on purpose. The write toolset (write_map with dry_run) and ops toolset (scan_codebase and convert_diagram via navo-cli) require explicit flags: allow-write with read-only disabled, and the right toolset allow-list. Git remains the system of record — agents draft and validate; humans still merge YAML through pull requests.
navo-mcp speaks stdio first and moors to Cursor, VS Code (Copilot MCP), Claude Desktop, Claude Code, Gemini CLI, Grok, and any host that spawns a local MCP server. Point NAVO_MAPS_DIR at your ArchitectureMap YAML locker, set toolsets to default, and keep read-only true for day-to-day agent use.
The model is not a security boundary. navo-mcp assumes curious arguments: progressive disclosure via toolsets, read-only defaults, path sandbox under the maps directory, payload and list caps, schema validation before write, and stderr-only logs so the protocol channel stays clean. No arbitrary shell, no production deploy control plane, no unrestricted filesystem.
Unlike screenshots or chat-pasted diagrams, MCP context is derived from versioned ArchitectureMap YAML. Changes land through pull requests and CI validation before agents or people see them. One chart for the SPA browser, the operator CLI, and every MCP-compatible agent — not a second ocean of truth.
An MCP (Model Context Protocol) architecture server exposes structured software-architecture data — maps, nodes, edges, and metadata — to AI tools and agents through a standard protocol. navo-mcp implements typed tools, navo:// resources, and prompts backed by Git YAML as the source of truth.
Default read-only toolsets are context (get_server_info, get_workspace_context), maps (list_maps, get_map_summary, get_map, search_maps), graph (get_node, list_nodes, get_edges, find_path, list_groups), and validate (validate_map, validate_yaml). Write and ops toolsets are opt-in behind explicit write gates.
Yes. The Community edition includes navo-mcp along with the interactive graph, wiki reader, operator CLI, and AI YAML generator. Read-only agent access is the default posture.
Any MCP host that can spawn a local stdio server: Cursor, VS Code, Claude Desktop, Claude Code, Gemini CLI, Grok, and similar coding agents. Configure command navo-mcp with args [stdio] and env NAVO_MAPS_DIR pointing at your YAML maps.
Only when you deliberately enable write. The default is read-only. With --allow-write, --read-only=false, and the write or ops toolsets, agents can validate and write YAML under the maps directory or run scan/convert via navo-cli. Structural team truth still merges through Git.
Reduce architecture drift and meetings. Unlimited viewers free. Community includes MCP, AI YAML, and Git as source of truth.