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, 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 (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=<id from a graph query>) 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=<name>) 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."

No code graphs pushed yet? Every tool answers with a clear "no code graph" message rather than guessing — set up the CI integration first.