rarefaction
Provides call graph and symbol context for C/C++ code through the project's language server, including callers, callees, implementations, type hierarchy, tests that reach the symbol, and live files affected by changes.
Provides call graph and symbol context for JavaScript code through the project's language server, including callers, callees, implementations, type hierarchy, tests that reach the symbol, and live files affected by changes.
Provides call graph and symbol context for Python code through the project's language server, including callers, callees, implementations, type hierarchy, tests that reach the symbol, and live files affected by changes.
Provides call graph and symbol context for Rust code through rust-analyzer, including callers, callees, implementations, type hierarchy, tests that reach the symbol, and live files affected by changes.
Provides call graph and symbol context for Swift code through sourcekit-lsp, including callers, callees, implementations, type hierarchy, tests that reach the symbol, and live files affected by changes.
Provides call graph and symbol context for TypeScript code through the project's language server, including callers, callees, implementations, type hierarchy, tests that reach the symbol, and live files affected by changes.
Provides call graph and symbol context for WebAssembly text (WAT) code through the project's language server, including callers, callees, implementations, type hierarchy, tests that reach the symbol, and live files affected by changes.
Rarefaction — LSP call graph MCP server for AI coding agents
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:columnpositions; 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 |
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.
# Claude Code
claude plugin install rarefaction --marketplace ip2k/rarefaction
# Codex
codex plugin marketplace add ip2k/rarefaction
codex plugin add rarefaction@rarefactionIn 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-mcpAdd --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 and orient (in Claude Code, mcp__rarefaction__status and
mcp__rarefaction__orient); both 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 = 180The 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. In mixed repositories pass profile or a workspace-relative path:line:column. 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 >> .gitignoreThen 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 |
|
|
|
|
Planned: scope (the live set as an enforceable working set — tree-shaking
for a task) and impacted_tests (the upward walk restricted to tests, as a
runnable selection). The live set is not yet a safe boundary for edits: on
real commits it contained a median half of the other files the change
touched (measurement), so scope waits on
widening it beyond call edges.
Languages and configuration
Profile | Language server | Prerequisites / scope |
| sourcekit-lsp | Xcode or a Swift toolchain; SwiftPM, or Xcode with a build-server config |
| rust-analyzer | Cargo.toml or rust-project.json; embedded/no_std/Wasm target settings supported; a project that pins a toolchain needs |
| clangd | C/C++; compile_commands.json or compile_flags.txt for accurate include paths and defines |
| typescript-language-server | TypeScript/JavaScript, TSX/JSX; server and TypeScript bundled as dependencies |
| Pyright | Python and stubs; bundled; configure interpreter/import paths for your environment |
| wat_server | WebAssembly |
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. Position queries discover the nearest supported
project marker. 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
2 toolsorientOrient on a symbolARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| up | No | How many levels of callers to walk (default 2: test cases usually sit one helper above the code they exercise). | |
| down | No | How many levels of callees to walk (default 1). | |
| symbol | Yes | A function, method, type or property: "updateLocation", "Engine.updateLocation", or an exact position "Sources/Engine.swift:204:10" (1-based line:column, on the name). | |
| profile | No | Source-language profile; required for bare names in mixed workspaces. | |
| project | No | Workspace-relative project directory, e.g. tools/driver for a nested Cargo package. | |
| max_nodes | No | Maximum graph nodes per direction and reference contexts; lower it for compact answers. | |
| include_body | No | Include the symbol's source body. | |
| max_body_lines | No | Truncate the body after this many lines. |
Output Schema
| Name | Required | Description |
|---|---|---|
| body | No | |
| root | No | |
| stats | Yes | |
| tests | Yes | |
| symbol | Yes | |
| callees | Yes | |
| callers | Yes | |
| profile | No | |
| warnings | No | |
| freshness | Yes | |
| truncated | Yes | |
| live_files | Yes | Files that can affect or be affected by the symbol within the walked depth. |
| references | No | For non-callables or servers without hierarchy: references grouped by file. |
| test_run_hint | No | |
| type_hierarchy | No | |
| implementations | Yes | |
| reference_contexts | No | |
| project_source_files | Yes | |
| external_callees_omitted | Yes | SDK / package callees dropped from `callees`. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safety (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, and the description still adds real behavioral context: the bounded graph size ("Compact"), the no-cross-language/FFI limitation, and the implicit cost signal behind the "increase only when needed" advice. It does not say how ambiguity or unresolved symbols are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with what the tool returns before how to call it. Every clause carries information: return contents, usage trigger, language scope, profiling caveat, limitation, and tuning rule. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description still covers what matters for correct invocation: language coverage, mixed-workspace profiling, graph-scope caveats, and depth-tuning guidance. Nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter guidance the schema does not state in one place: the profile/path:line:column fallback for mixed workspaces and a rationale for keeping up/down low. It is silent on max_nodes, include_body, max_body_lines, and project, which the schema already carries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (orient) on a specific resource (a symbol) and enumerates exactly what context is returned: signature, body, callers, callees, tests, implementations, relevant files. It also names the source of truth (language-server indexes), which is enough to distinguish it from the lone sibling status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit usage context ("Use before broad file reads"), the supported languages, the mixed-workspace routing rule (specify profile or use path:line:column), and a tuning rule ("Increase up/down only when needed"). It does not name the sibling status or state when-not to call it, so it falls just short of the top band.
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 statusARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Source-language profile; required for bare names in mixed workspaces. | |
| project | No | Workspace-relative project directory, e.g. tools/driver for a nested Cargo package. |
Output Schema
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| profiles | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds the content scope (freshness, compile flags) but says nothing about cost, latency, or what happens when the index is stale/absent, so it adds only modestly beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each doing distinct work: what is reported, when to call, and how to scope. The action is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies the pre-call context, sibling routing, and parameter scoping an agent needs to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already documented in the schema (enum values for profile, example path for project). The description adds a small amount of meaning by tying both parameters to the 'inspect a nested package' scenario rather than just repeating their types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Check') plus a concrete resource list: detected source-language profiles, project roots, executables, compile flags and freshness. It also positions itself against the sibling by framing the call as a pre-flight step to 'orient', so an agent can tell the two apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('call once before orient in a new project or when orientation is incomplete') and names the alternative tool. It also covers the secondary scenario of inspecting a nested package via profile/project, leaving little to inference.
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.
2 tool updates
v0.2.2- First observed
orient - First observed
status
TDQS
Scored across 2 tools
orient performs the actual context retrieval while status is a diagnostic/setup check for profiles and freshness. The two purposes are clearly distinct with no overlap, and the descriptions explicitly state the call order (status before orient).
Both names are single lowercase tokens in a consistent style, but one is a verb (orient) and the other a noun (status), so there is no single predictable verb_noun convention. Still readable and non-chaotic.
Only two tools for a code-orientation/LSP-indexing domain feels thin; the surface is tightly scoped but leaves little room for related operations. It borders on under-provisioned for the apparent scope.
The pair covers orientation and environment checking, which are the core workflow, but there is no way to refresh/rebuild indexes, enumerate indexed projects, or query symbols separately. Notable gaps exist that an agent may hit in larger workflows.
Maintenance
Related MCP Connectors
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Repository knowledge graph MCP server for codebase understanding and debugging.
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol (MCP) server designed to easily dump your codebase context into Large Language Models (LLMs).16 npm3Apache 2.0
- FlicenseNot gradedqualityDmaintenanceA lightning-fast, language-agnostic code analysis MCP (Model Context Protocol) server built in Rust9-
- AlicenseNot gradedqualityAmaintenanceStandalone 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.6Apache 2.0
- AlicenseBqualityDmaintenanceInstant codebase knowledge graph MCP server. It auto-detects languages, indexes functions, classes, and call chains, enabling LLMs to navigate code in milliseconds.24MIT