> For the complete documentation index, see [llms.txt](https://docs.controltheory.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.controltheory.com/controltheory-documentation/dstl8-docs/code-graph/mcp-tools.md). # MCP Tools The six code tools — resolve patterns to source, expand deploys into change sets, trace blast radius Once at least one repo has [pushed a code graph](/controltheory-documentation/dstl8-docs/code-graph.md), six `code` tools appear on your org's MCP server. Möbius uses them during investigations; you get the same tools in Claude Code, Cursor, Claude Desktop, and anything else connected through [MCP integration](/controltheory-documentation/dstl8-docs/mcp-integration.md) (via `dstl8 mcp` or your org's MCP endpoint). All six are read-only. Results are compact markdown with a `Next steps:` footer pointing at the natural follow-up tool. ## list\_code\_repos Lists the repos with a pushed code graph — services they build, log-site counts, and graph freshness. Call it first for situational awareness; if it reports no code graphs, the other tools have nothing to answer from. **Inputs:** none. > "Which of our repos have code graphs?" ``` # Code graphs (2 repos) - github.com/acme/checkout (main): services=[checkout, checkout-worker], 1240 log sites, 391 files, graph from 2026-08-12 commit 9f2c1ab - github.com/acme/billing (main): services=[billing], 480 log sites, 122 files, graph from 2026-08-10 commit 4d0e8c2 --- Next steps: code_for_pattern(template_id) to place an erroring pattern in source | code_changes(event_id) to see what a deploy shipped ``` ## code\_for\_pattern Resolves one error pattern to the source code that emits it: repo, `file:line`, function, and the commit that last shipped it. Set **exactly one** of `template_id` or `log_line`. **Inputs:** | Field | Description | | ------------- | ---------------------------------------------------------------------------------- | | `template_id` | A `pt-…` pattern ID (from `query_patterns` or an incident's evidence fingerprints) | | `log_line` | Alternative: one raw log line to locate in source | | `service` | Optional: only return sites in repos that build this service | | `limit` | Max matches (default 5) | > "Where in the code does `pt-ab12cd34ef` come from?" ``` # Source locations for pt-ab12cd34ef (1) - github.com/acme/checkout payments/client.go:212 chargeCard() [exact 1.00] service=checkout commit=9f2c1ab --- Next steps: quote file:line when citing this as evidence | code_changes(event_id) to check whether a deploy in the window touched these files ``` Each match is tagged `[exact 1.00]` or `[contained 0.94]` — `exact` means the runtime pattern's fingerprint equals the format string's fingerprint; `contained` is a scored token-containment match (structured loggers append fields at runtime, so the runtime line is often a superset of the format string). When several identical format strings exist, all candidate sites are returned — the one named in other evidence (or touched by a recent deploy) is the likely one. ## code\_changes Expands a deploy into what it shipped, at file and log-statement level. Prefer passing a platform event ID; a raw commit range works too. **Inputs:** | Field | Description | | --------------------- | ---------------------------------------------------------------------------------- | | `event_id` | A `deploy` or `ci` platform event ID from `list_events` (preferred) | | `repo` | Alternative: repo key (`github.com/owner/name`) — requires `from_sha` and `to_sha` | | `from_sha` / `to_sha` | Older / newer commit SHA (with `repo`) | > "What did the checkout deploy at 13:58 actually change?" ``` # Code changes in github.com/acme/checkout 11aa22b..9f2c1ab Services affected: checkout ## Files changed (3) - payments/client.go - payments/retry.go - go.mod ## Log statements added (1) - payments/client.go:212 chargeCard() [error] "connection refused to <*> after <*> retries" (pt-ab12cd34ef) --- Next steps: code_for_pattern(template_id) to check whether an erroring pattern lives in a changed file | cite this event id and file:line together when naming a probable cause ``` Two caveats surface directly in the output when they apply: if no snapshot exists at the event's exact commit, the nearest later snapshot is used (`NOTE: … treat file lists as approximate`), and if the snapshot chain doesn't reach `from_sha`, the change set is a partial union. ## find\_symbol Finds where a function, method, class, or type is defined across all pushed code graphs. Use it to place a name from a stack trace or error message. **Inputs:** `query` (name or fragment, e.g. `chargeCard`), `limit` (default 20). > "Where is chargeCard defined?" ``` # Symbols matching "chargeCard" (1) - github.com/acme/checkout chargeCard payments/client.go:198 [function] --- Next steps: code_impact(repo, node_kind=symbol, node_id=) for what contains it | quote path:line when citing ``` Symbols only exist for repos pushed with a current CLI (and without `--no-symbols`) — `list_code_repos` shows per-repo symbol counts. ## code\_impact Blast radius inside a repo's code graph: what contains or depends on a file, symbol, service, or external dependency, grouped by hop distance. Turns "file X changed" into "services A and B are affected", or "stripe SDK" into "these files use it". **Inputs:** | Field | Description | | ----------- | ----------------------------------------------------------------------------------------------- | | `repo` | Repo key (`github.com/owner/name`) or unambiguous short name | | `node_kind` | `file` \| `symbol` \| `service` \| `external_dep` | | `node_id` | File path for `file`; name for `service`/`external_dep`; `sym-…` ID for `symbol` | | `direction` | `dependents` (what breaks if this breaks) \| `dependencies` (what it needs) \| `both` (default) | | `depth` | Traversal depth 1–5 (default 3) | > "If payments/client.go is broken, what's affected?" ``` # Code impact of file payments/client.go in github.com/acme/checkout (direction: both) ## 1 hop(s) away - service checkout (via builds) - file payments/retry.go (via imports) ## 2 hop(s) away - external_dep github.com/stripe/stripe-go (via depends_on) --- Next steps: services listed here are the deploy's potential blast radius | name only nodes listed here as affected ``` ## service\_dependencies The services a repo builds and its third-party dependencies (SDKs, libraries). Use it when a third-party outage is suspected: a status-page event for a provider whose SDK appears here is correlation evidence. **Inputs:** `repo`. > "Does anything in checkout depend on Stripe?" ``` # github.com/acme/checkout ## Services (2) - checkout (dstl8_yaml) - checkout-worker (dstl8_yaml) ## External dependencies (3) - github.com/stripe/stripe-go [go] - github.com/aws/aws-sdk-go-v2 [go] - github.com/segmentio/kafka-go [go] --- Next steps: a third-party outage (status-page event) plus that provider's SDK here = correlation evidence | code_impact(repo, node_kind=external_dep, node_id=) shows which files use it ``` ## The deploy-correlation recipe The workflow that turns "errors started after the deploy" into a cause with receipts — this is what Möbius does, and it works just as well when you drive it yourself from Claude Code or Cursor: 1. **Find the change.** `list_events` (or the incident's related events) → a `deploy`/`ci` event in the window before the spike, with its `ev_…` ID. 2. **Expand it.** `code_changes(event_id)` → the files that deploy changed and any log statements it added or removed. 3. **Place the symptom.** `code_for_pattern(template_id)` with the erroring pattern's `pt-…` fingerprint (from `query_patterns` or the incident's evidence) → the `file:line` that emits it. 4. **Join them.** If the erroring pattern's file appears in the deploy's changed files, cite **both together**: the event ID and the `file:line`. That's naming evidence — "deploy `ev_…` changed `payments/client.go`, and the erroring pattern `pt-ab12cd34ef` is emitted from `payments/client.go:212` in `chargeCard()`." A prompt that triggers the whole chain: > "Errors spiked in checkout around 14:00. Did a deploy cause it? If so, name the file and line." {% hint style="info" %} No code graphs pushed yet? Every tool answers with a clear "no code graph" message rather than guessing — set up the [CI integration](/controltheory-documentation/dstl8-docs/code-graph/ci.md) first. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.controltheory.com/controltheory-documentation/dstl8-docs/code-graph/mcp-tools.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.