Skip to main content
Glama

Rarefaction — LSP call graph MCP server for AI coding agents

CI npm License: GPL v3+ ip2k/rarefaction MCP server

Rarefaction is a Model Context Protocol (MCP) server that gives a coding agent the call graph and code context for one symbol straight from the project's language server (Language Server Protocol, LSP). Ask about a function, method or type and get, in one call: its signature and doc, its body, who calls it (tests marked), what it calls, who implements it, the tests that reach it and the short list of files a change can affect. The agent reads that instead of opening whole files and grepping, which keeps its context window small and spends fewer tokens on exploration.

Works with Claude Code, Codex and any MCP client over stdio. Profiles cover Swift, Rust, C/C++, TypeScript/JavaScript, Python and WebAssembly text (WAT).

Run against the bundled TypeScript fixture (fixtures/SampleTypeScript):

# scale — engine.ts:2:17

```
function scale(value: number): number
```

Double one input sample.

## Callers (2, 1 in tests)
- render — render.ts:2 (calls at 3)
- · testScale — engine.test.ts:2 (calls at 3) [test]

## Tests that reach it (1)
- testScale — engine.test.ts:2

Run only these:
```
npm test -- "engine.test.ts"
```

## Live files (3 of 3)
- engine.test.ts
- engine.ts
- render.ts

_11 LSP requests, 6430 ms (includes language-server cold start); index on-open_

Once the language server has indexed, a call takes a fraction of a second (median 80 ms on ripgrep, 220 ms on the 800-file IronRDP workspace); the server's cold start, 6–16 s on those projects, is paid once per session.

What it helps with

  • Reducing token usage in AI coding agents. One bounded answer replaces several whole-file reads and searches. Measured on 50 real commits in ripgrep and IronRDP, the answer was a median 6–7% of the bytes of reading the files it names once. How much that saves in a whole agent session is not measured yet; see docs/measurement.md, including where the live set falls short.

  • Call graph and impact analysis. "What calls this function, and what would break if I change it?" By default two levels of callers and one of callees, plus implementations and type hierarchy, each bounded and marked when truncated.

  • Choosing which tests to run. Tests that reach the symbol, with a "run only these" command for the project's test runner.

  • Orientation in an unfamiliar codebase. Bare names, qualified names or exact path:line:column positions; ambiguity comes back as a list of exact positions rather than a guess.

  • Honest answers about coverage. Stale indexes, servers still indexing and servers without call hierarchy are reported in the answer, not hidden.

Related MCP server: CodeCortX-MCP

Why an MCP server for LSP call graphs

Language servers already know the call graph precisely — that is what "find references" and "call hierarchy" are. Editors and LSP tools expose them one hop at a time, so an agent pays a tool call and a round of context per hop. An agent needs the closure: everything within a couple of hops, filtered to the project, with the tests picked out, small enough to read in one go. That composition is what this server does. It is deliberately language-agnostic: the core speaks LSP and nothing else, and everything a language needs is a small profile.

How it relates to nearby tools:

approach

what the agent gets

reading files and grep

whole files; text matches, not calls

per-request LSP tools (definition, references, call hierarchy)

precise answers, one hop per tool call

Serena

symbol navigation and semantic editing over LSP; works well alongside this

Rarefaction

the bounded multi-hop call graph, tests and live files for one symbol in one call

Install

Requires Node 22.22.2 or later; used on macOS and Linux (CI runs on Ubuntu), untested on Windows. The TypeScript and Python language servers are bundled. Install the others you need and put them on the PATH your client launches with — see Languages and configuration. Swift needs macOS with Xcode (or a Swift toolchain with sourcekit-lsp).

As a plugin (Claude Code and Codex)

The plugin bundles the server, launched with npx -y rarefaction-lsp-mcp, and an orient-first skill that tells the agent to call status and orient before reading whole files, and scope before editing.

# Claude Code
claude plugin install rarefaction --marketplace ip2k/rarefaction

# Codex
codex plugin marketplace add ip2k/rarefaction
codex plugin add rarefaction@rarefaction

In a Claude Code session, /plugin install rarefaction --marketplace ip2k/rarefaction does the same. Restart or reconnect the session afterwards.

As an MCP server

claude mcp add --scope user --transport stdio rarefaction -- npx -y rarefaction-lsp-mcp
codex mcp add rarefaction -- npx -y rarefaction-lsp-mcp

Add --env PATH="$HOME/.local/bin:$HOME/.cargo/bin:$PATH" before the -- if rust-analyzer or wat_server live outside the client's PATH. The tools are status, orient and scope (in Claude Code, mcp__rarefaction__status, mcp__rarefaction__orient and mcp__rarefaction__scope); all three are read-only, so you can allow them in your permissions to avoid repeated prompts. For Codex, give the first index time in ~/.codex/config.toml:

[mcp_servers.rarefaction]
startup_timeout_sec = 20
tool_timeout_sec = 180

The server takes --root <path> and --profile <id>. Explicit --root takes precedence over Claude Code's CLAUDE_PROJECT_DIR, then the working directory. Leave both unset in a user-wide registration so every project can use all supported profiles. See the MCP documentation for Claude Code and Codex.

From a clone

To run your own changes, build and register the compiled entry instead:

git clone https://github.com/ip2k/rarefaction.git
cd rarefaction
npm ci && npm run build
claude mcp add --scope user --transport stdio rarefaction -- "$(command -v node)" "$PWD/dist/index.js"

Rebuild after changing the server, then restart or reconnect (/mcp) the client session.

Check it works

Start a new chat in a project and ask the agent to call status, then orient on a symbol you know. status.root should match the project and the selected entry in status.profiles should have ok: true. One registration serves all supported languages; each language server starts lazily.

Agent guidance

The plugin's skill covers this. Without the plugin, add this to ~/.claude/CLAUDE.md, AGENTS.md or a project instruction file:

Use rarefaction's status tool once in a new project, then orient on the relevant symbol before reading whole files, and scope on a symbol before editing it (advisory: also look outside the files it lists). In mixed repositories pass profile or a workspace-relative path:line:column, and pass project for a nested package that is not a workspace member. Start with the default graph bounds; expand only when necessary. Follow freshness and coverage advice, and inspect FFI/generated bindings separately when relevant.

Xcode projects

Xcode projects need a build-server config so sourcekit-lsp gets compiler flags (SwiftPM packages need nothing):

brew install xcode-build-server
cd /path/to/App && xcode-build-server config -project App.xcodeproj -scheme App
echo buildServer.json >> .gitignore

Then build once in Xcode or with xcodebuild; the index is only as fresh as the last build, and orient says so when a source file is newer. Saved source edits are sent to open LSP documents before later queries, but Xcode projects still need a new build to refresh their cross-file index.

Tools

tool

what

orient

{symbol, profile?, project?, up?, down?, max_nodes?, include_body?, max_body_lines?} — the bundle above. symbol may be updateLocation, Engine.updateLocation, or path/File.swift:204:10. Ambiguous names come back as an error listing exact positions.

scope

{symbol, profile?, project?, up?, down?, max_nodes?} — the working set for a change to that symbol: the call-graph files from orient plus files that have historically changed in the same commits as the symbol's file or the call-graph files (from git history), each with its reason. Advisory: it lists what to read and check, not what is safe to ignore (measured coverage).

status

{profile?, project?} — what the server can see: the profile inventory and which one is selected, prerequisites such as a build-server config, index freshness, and which LSP features the server offers. Call this first if orient finds nothing.

Planned: impacted_tests (the upward walk restricted to tests, as a runnable selection).

Languages and configuration

Profile

Language server

Prerequisites / scope

swift

sourcekit-lsp

Xcode or a Swift toolchain; SwiftPM, or Xcode with a build-server config

rust

rust-analyzer

Cargo.toml or rust-project.json; embedded/no_std/Wasm target settings supported; a project that pins a toolchain needs rustup component add rust-analyzer --toolchain <channel> (status says so)

c

clangd

C/C++; compile_commands.json or compile_flags.txt for accurate include paths and defines

typescript

typescript-language-server

TypeScript/JavaScript, TSX/JSX; server and TypeScript bundled as dependencies

python

Pyright

Python and stubs; bundled; configure interpreter/import paths for your environment

wasm

wat_server

WebAssembly .wat text; install the prebuilt server on PATH

The server probes each language server's capabilities. When call hierarchy is absent, orient reports references and enclosing symbols, without claiming those references are calls. Native Rust/C sources compiled to WebAssembly use rust/c; .wasm binaries need disassembly to .wat. WAST test scripts, vendor assembly, indirect runtime dispatch and cross-language FFI edges are not indexed as a unified graph.

Optional .rarefaction.json in the workspace root configures each profile. Paths in project, profile root, and relative position queries are relative to that workspace. A position query without project is answered from the outermost Cargo workspace that takes the file's crate in (as a member, a package.workspace pointer or a path dependency of the root package), else from the nearest supported project marker. When that leaves part of an enclosing project out, the answer carries a warning that says so and which project to pass. TypeScript is the exception: the TypeScript language server answers one tsconfig.json project at a time, so in an npm, yarn or pnpm workspace with a tsconfig.json per package, callers in other packages are not listed, with or without project, and the warning says that too. The search stops at a directory holding .git, so a position in a git worktree, submodule or other checkout nested inside the workspace is answered from that checkout alone; give positions its path as a prefix, and name it in project for bare names. Bare names in mixed workspaces need profile or a configured default_profile:

{
  "default_profile": "typescript",
  "profiles": {
    "rust": {
      "root": "firmware/rust",
      "initializationOptions": {
        "cargo": { "target": "thumbv7em-none-eabihf", "features": ["board"] }
      }
    },
    "c": { "args": ["--background-index", "-j=2", "--compile-commands-dir=/absolute/local/build"] },
    "python": {
      "initializationOptions": { "python": { "pythonPath": "/absolute/project/.venv/bin/python" } }
    }
  }
}

command, args, env, and initializationOptions may override each profile's launch settings; initialization objects merge recursively. args replaces the defaults. Rust cargo checks, build scripts and proc macros are disabled by default to avoid incidental compilation; enable them explicitly when your project needs generated/expanded code. After changing this configuration, restart the MCP connection. Missing executables appear in status with setup advice.

Graph output defaults to 50 nodes per direction, two caller levels, one callee level and 80 body lines. Use max_nodes, up, down, or include_body: false to adjust context size. Truncation is explicit. Name lookup without a workspace index falls back to scanning at most 200 source files; use an exact position or a smaller project when needed.

See embedded C, JieLi and WebAssembly setup for analysis compilation databases and target limitations.

Serena alongside Rarefaction

Serena complements this server with symbol navigation, diagnostics and semantic edits. docs/serena.md covers a pinned installation, a WAT adapter, project language settings, limitations and verification.

Privacy

Rarefaction runs entirely on your machine. It reads your project's files and talks to language servers over local stdio; it makes no network requests and collects no telemetry. The language servers it launches behave as they do in your editor (for example, rust-analyzer runs cargo metadata, which may fetch crate indexes). npx downloads the package from npm on first use.

Development

npm ci && npm run build
npm test                        # unit + real LSP integration; external servers skipped if absent
claude plugin validate .        # plugin and marketplace manifests
node scripts/verify-codex.mjs   # exercise the registered MCP through Codex, no model turn
npx tsx scripts/try.ts --root fixtures/SampleTypeScript orient '{"symbol":"scale"}'

The logo and icon (Rosé Pine Moon) come from python3 tools/render_logo.py; the README diagrams (Dawn for light, Moon for dark) from python3 tools/render_diagrams.py. The fixtures under fixtures/ are small synthetic projects, one per language. CI runs the suite with clangd and rust-analyzer installed. The Release workflow (a v* tag push, or "Run workflow" on main) checks that every version field agrees (package.json, server.json, both plugin manifests), publishes to npm and the MCP Registry as io.github.ip2k/rarefaction-lsp-mcp, then creates the GitHub release. docs/measurement.md states the thresholds the project holds itself to; docs/decisions.md records why things are the way they are.

Licence

Copyright (C) 2026 Sean (ip2k).

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. It is distributed WITHOUT ANY WARRANTY; see LICENSE for the full text.

Available Tools

3 tools
orientOrient on a symbolA
Read-onlyIdempotent

Compact source context from language-server indexes: signature, body, callers, callees, tests, implementations and relevant files. Use before broad file reads in Swift, Rust, C/C++, TypeScript/JavaScript, Python and WebAssembly WAT projects. In mixed workspaces specify profile or use path:line:column. No cross-language/FFI edges are inferred. Increase up/down only when needed.

NameRequiredDescriptionDefault
upNoHow many levels of callers to walk (default 2: test cases usually sit one helper above the code they exercise).
downNoHow many levels of callees to walk (default 1).
symbolYesA function, method, type or property: "updateLocation", "Engine.updateLocation", or an exact position "Sources/Engine.swift:204:10" (1-based line:column, on the name).
profileNoSource-language profile; required for bare names in mixed workspaces.
projectNoWorkspace-relative project directory, e.g. tools/driver for a nested Cargo package. Without it, a path:line:column symbol is answered from its enclosing Cargo workspace, else from its nearest project marker (a warning says when that leaves part of the workspace out).
max_nodesNoMaximum graph nodes per direction and reference contexts; lower it for compact answers.
include_bodyNoInclude the symbol's source body.
max_body_linesNoTruncate the body after this many lines.

Output Schema

NameRequiredDescription
bodyNo
rootNo
statsYes
testsYes
symbolYes
calleesYes
callersYes
profileNo
warningsNo
freshnessYes
truncatedYes
live_filesYesFiles that can affect or be affected by the symbol within the walked depth.
referencesNoFor non-callables or servers without hierarchy: references grouped by file.
test_run_hintNo
type_hierarchyNo
implementationsYes
reference_contextsNo
project_source_filesYes
external_callees_omittedYesSDK / package callees dropped from `callees`.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds real behavioral context beyond that: the absence of cross-language/FFI edges, the default-walk rationale (test cases usually sit one helper above), and a warning that project resolution can silently omit part of a workspace. It does not describe cost or latency for large max_nodes values, keeping it just short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences, front-loaded with what the tool returns, then usage, then the mixed-workspace caveat, then tuning. Every sentence carries information that is not already in the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return shape, and with annotations it needn't justify safety. It still covers language support, workspace ambiguity, graph-walk limits and the FFI blind spot — everything an agent needs to invoke this correctly with eight parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema itself documents defaults, ranges and symbol formats in detail, so the baseline is 3. The description contributes only the mixed-workspace routing rule for profile versus path:line:column and the 'increase up/down only when needed' heuristic, which are useful but marginal against a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates exactly what comes back — signature, body, callers, callees, tests, implementations, relevant files — which lets an agent distinguish it from the status/scope siblings at a glance. It lacks a crisp single verb+resource phrase ('source context from language-server indexes' is close) but the enumeration is concrete enough that no ambiguity remains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the timing explicitly ('Use before broad file reads'), names the supported languages, and gives a conditional fallback for mixed workspaces (specify profile or use path:line:column). It also states a tuning rule ('Increase up/down only when needed') and a hard limitation ('No cross-language/FFI edges are inferred'), which is exactly the when/when-not guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scopeWorking set for a changeA
Read-onlyIdempotent

The files a change to one symbol is likely to touch: orient's call-graph files (callers, callees, implementations, tests) plus files that have historically changed in the same commits as the symbol's file, each with its reason. Use when planning an edit, to know which files to read and check. Advisory, not a boundary: real changes often touch files outside it.

NameRequiredDescriptionDefault
upNoHow many levels of callers to walk (default 2: test cases usually sit one helper above the code they exercise).
downNoHow many levels of callees to walk (default 1).
symbolYesA function, method, type or property: "updateLocation", "Engine.updateLocation", or an exact position "Sources/Engine.swift:204:10" (1-based line:column, on the name).
profileNoSource-language profile; required for bare names in mixed workspaces.
projectNoWorkspace-relative project directory, e.g. tools/driver for a nested Cargo package. Without it, a path:line:column symbol is answered from its enclosing Cargo workspace, else from its nearest project marker (a warning says when that leaves part of the workspace out).
max_nodesNoMaximum graph nodes per direction and reference contexts; lower it for compact answers.

Output Schema

NameRequiredDescription
rootYes
filesYesThe working set: symbol file first, then call-graph files, then files found only through history or links.
statsYes
countsYes
symbolYes
profileYes
warningsYes
co_changeYes
truncatedYesThe call-graph walk hit max_nodes.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/idempotent/closed-world, so the description focuses on what annotations cannot say: that results are advisory and incomplete by nature, and that each file comes with a reason. That reliability caveat is genuinely useful and not derivable from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: composition, when to use, and the key caveat — front-loaded with the resource definition and no filler. Every sentence contributes distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% parameter coverage, the description only needs to frame purpose and limitations, which it does. Minor gap: it doesn't hint at profile/project resolution caveats, though the schema carries those details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameter documentation is already fully handled. The description only indirectly illuminates the up/down depth parameters via the caller/callee/test enumeration; it adds no syntax or default guidance beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the concrete output — the set of files a change to one symbol is likely to touch — and specifies how that set is composed (callers, callees, implementations, tests plus historically co-changed files). This is clearly distinct from the sibling `orient` (call-graph) and `status`, so an agent can choose without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use when planning an edit, to know which files to read and check" gives an explicit triggering situation, and "Advisory, not a boundary" sets expectations about when not to over-trust the result. It stops short of naming an alternative tool or a when-not-to-call condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statusProject, language server and index statusA
Read-onlyIdempotent

Check detected source-language profiles, project roots, executables, compile flags and freshness. Call once before orient in a new project or when orientation is incomplete. Pass profile/project to inspect a nested package.

NameRequiredDescriptionDefault
profileNoSource-language profile; required for bare names in mixed workspaces.
projectNoWorkspace-relative project directory, e.g. tools/driver for a nested Cargo package. Without it, a path:line:column symbol is answered from its enclosing Cargo workspace, else from its nearest project marker (a warning says when that leaves part of the workspace out).

Output Schema

NameRequiredDescription
rootYes
profilesYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds useful behavior in 'call once' semantics and the fallback warning ('a warning says when that leaves part of the workspace out'), but reveals nothing about cost, latency, or what 'freshness' means operationally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, with the substantive content front-loaded ahead of the usage trigger. Every sentence carries a distinct payload: what is returned, when to call, and how to target a nested package.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and both optional params fully documented in the schema, the description needn't explain return values, and it doesn't try. It covers purpose, timing and scoping adequately; only the term 'freshness' and the absent 'scope' relationship leave small gaps for a zero-required-parameter inspection tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the 'project' parameter description is already richer than the tool description (enclosing Cargo workspace, nearest project marker). The description adds only a light framing — 'Pass profile/project to inspect a nested package' — which the schema already conveys in more detail. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description upgrades the vague name 'status' into a concrete enumeration: 'detected source-language profiles, project roots, executables, compile flags and freshness.' It partially differentiates from siblings by naming 'orient' as the follow-up step, but never clarifies its relationship to 'scope', leaving one sibling boundary implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger — 'Call once before orient in a new project or when orientation is incomplete' — which is actionable and ties directly to the sibling. A second sentence covers the nested-package case. It lacks any when-not guidance or a stated alternative for the ambiguous 'scope' sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.4.2
    • Changedorient1 field changed
      • changedInput schema / properties / project / description
        Previous value: -"Workspace-relative project directory, e.g. tools/driver for a nested Cargo package."New value: +"Workspace-relative project directory, e.g. tools/driver for a nested Cargo package. Without it, a path:line:column symbol is answered from its enclosing Cargo workspace, else from its nearest project marker (a warning says when that leaves part of the workspace out)."
    • Changedscope8 fields changed
      • changedInput schema / properties / project / description
        Previous value: -"Workspace-relative project directory, e.g. tools/driver for a nested Cargo package."New value: +"Workspace-relative project directory, e.g. tools/driver for a nested Cargo package. Without it, a path:line:column symbol is answered from its enclosing Cargo workspace, else from its nearest project marker (a warning says when that leaves part of the workspace out)."
      • removedOutput schema / properties / co_change / properties / anchor_commits / maximum
        Removed value: -9007199254740991
      • removedOutput schema / properties / co_change / properties / anchor_commits / minimum
        Removed value: --9007199254740991
      • changedOutput schema / properties / co_change / properties / anchor_commits / type
        Previous value: -"integer"New value: +"number"
      • addedOutput schema / properties / counts / properties / link_only
        Added value: +{
        +  "maximum": 9007199254740991,
        +  "minimum": -9007199254740991,
        +  "type": "integer"
        +}
      • changedOutput schema / properties / counts / required
        Previous value: -[
        -  "files",
        -  "call_graph",
        -  "co_change",
        -  "co_change_only",
        -  "project_source_files"
        -]New value: +[
        +  "files",
        +  "call_graph",
        +  "co_change",
        +  "co_change_only",
        +  "link_only",
        +  "project_source_files"
        +]
      • changedOutput schema / properties / files / description
        Previous value: -"The working set, symbol file first, then call-graph files, then co-change-only files."New value: +"The working set: symbol file first, then call-graph files, then files found only through history or links."
      • changedOutput schema / properties / files / items / properties / sources / items / enum
        Previous value: -[
        -  "symbol",
        -  "call_graph",
        -  "co_change"
        -]New value: +[
        +  "symbol",
        +  "call_graph",
        +  "co_change",
        +  "link"
        +]
    • Changedstatus1 field changed
      • changedInput schema / properties / project / description
        Previous value: -"Workspace-relative project directory, e.g. tools/driver for a nested Cargo package."New value: +"Workspace-relative project directory, e.g. tools/driver for a nested Cargo package. Without it, a path:line:column symbol is answered from its enclosing Cargo workspace, else from its nearest project marker (a warning says when that leaves part of the workspace out)."
  2. 1 tool updatev0.3.0
    • Addedscope
  3. 2 tool updatesv0.2.2
    • First observedorient
    • First observedstatus

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation4/5

The three tools have distinct roles: status is a preflight check, orient retrieves symbol context, and scope predicts change impact. There is minor overlap in that status and orient both reference profiles, but the descriptions clearly separate their purposes.

Naming Consistency3/5

All names are single lowercase words with no underscores or camelCase, which is visually consistent. However, they mix grammatical roles (status is a noun, orient is a verb, scope is ambiguous), so there is no predictable verb_noun pattern.

Tool Count4/5

Three tools is a tight, focused set for a code-orientation server, and each tool serves a clear step in the workflow. The count is slightly minimal but reasonable given the narrow scope.

Completeness3/5

The surface covers preflight, context retrieval, and impact analysis, but lacks any symbol search or discovery operation—users must already know a path:line:column. This is a notable gap for a code intelligence tool, though core workflows are partially supported.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    A lightning-fast, language-agnostic code analysis MCP (Model Context Protocol) server built in Rust
    9
    -
  • A
    license
    Not graded
    quality
    A
    maintenance
    Standalone MCP server for code structure analysis using tree-sitter. Directory trees, symbol definitions, and call graphs without reading raw source files. Supports Rust, Python, Go, Java, TypeScript, Fortran, JavaScript, C/C++, and C#. Benchmarked up to 68% fewer tokens vs native tools.
    7
    Apache 2.0
  • A
    license
    A
    quality
    A
    maintenance
    Call graph MCP server for Rust, Python, TypeScript, TSX, and JavaScript. Every caller and callee carries a resolution field showing how the reference was matched to a definition, plus multi-hop impact analysis for refactoring. Local-only, single binary, no network egress. Benchmarked against grep, ripgrep, and ctags on a 120-item hand-verified golden set, including the cases where it loses.
    3
    MIT