Closedloop Intel

General orientation (fallback, and useful context either way)

closedloop-graph is the single MCP server for ClosedLoop ticket and code intelligence. It has three tool families, and the routing question is always which family a question belongs to:

• The ledger tools are the fast warehouse: use them for anything countable or temporal (shipped, WIP, collisions, full-text search, ticket detail, blast-radius ticket lists, read-only SQL). Milliseconds. Never use graph search for aggregates.
• The ticket-graph tools are the semantic half: use the node-search and fact-search tools, scoped to the tickets group, for scope overlap, shared components, and why-do-these-relate questions. Seconds, not milliseconds.
• The code-graph tools (code_projects, code_symbols, code_callers, code_tests_for, code_importers, code_snippet, code_grep, code_architecture) answer about the source itself: definitions, callsites, quoted source, which test files and which other files import a given source file, and package or entry-point structure. They take a short repo name like symphony-alpha, never a project identifier. Call code_projects first if you do not know what is indexed, then keep the names it gives you: it is the expensive one here (about 670 ms warm, several seconds on the first call after a host restart), while code_symbols and code_architecture cost tens of milliseconds and code_grep is the outlier at a few seconds on the largest repository.

The names invert between the last two families, so settle which family before you pick a verb: the ticket graph searches entities a ticket mentioned, the code graph searches symbols that exist in the tree.

Every tool on the server is read-only. There are no write operations to reach for and none to avoid.

Cite ticket slugs and file paths in every answer. If something is not in the indexes, say so rather than guessing.

What you have and do not have, as a remote client

You get both halves of a blast radius, over the one registration: the ticket half (ledger queries, full-text search, ticket detail, aggregate rollups, ticket-graph semantic search) and the code half (symbols, callers, snippets, grep, architecture), on the same URL under the same token. There is no second server to register and no local checkout to index first. Answer both halves and say which half each claim came from.

Two things genuinely stay on the host:

• Raw Cypher against the code graph, and its schema. The ticket graph's read-only Cypher escape hatch is on this connection; the code graph's is not. Ask the code_* tools rather than composing a traversal.
• Anything that writes. Re-indexing a repository, mutating or deleting an index: those exist only on the host machine. This endpoint deliberately carries no write tool at all.

One caveat that is a property of the index rather than of the connection: the code graph tracks each repository's default branch, so an answer from it is an answer about main, never about anyone's uncommitted or branch-local work. code_projects reports the head_sha, branch and status it is answering at; quote them when freshness matters.

One boundary that bites hardest on machines that ALSO hold a checkout of closedloop-intel: that checkout is a different deployment, not a window into this one. Never run its just commands, open its ledger.db, or read its mirrors to answer or diagnose questions here; evidence comes over this connection, and host remedies belong to the host operator. If you deliberately compare against local source anyway, say so and state both commits, the mirror's head_sha and your checkout's HEAD.