What can you do with this server?

ContextSmith is a local MCP server that gives coding agents task-relevant, token-budgeted code context from an indexed repository. * get_context: return the most relevant code for a task, packed into a chosen token budget. * search: find ranked functions, classes, and methods matching a query. * find_symbol: locate where a function, class, or method is defined, with signature. * callers / callees: inspect one hop of the call graph. * impact: list everything that transitively calls a symbol, showing possible blast radius. * related_files: find files linked by imports/calls or historical co-change. * add_note: store a decision, invariant, or gotcha pinned to a file or symbol. * overview: summarize repository languages, size, central files, and most-changed files. * reindex: incrementally re-index changed files.

Which integrations are available for this server?

Reads the repository's git history as a retrieval signal: commit messages are indexed with BM25 so past commits touching similar bugs surface the right files, and co-change pairs expose files that change together. Exposed to agents through tools like related_files, which returns files linked by code plus files that historically change together.

How do I use ContextSmith?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ContextSmith get the most relevant code for the duplicate coupon bug, 4000 token budget" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ContextSmith

by RahulSankhla312

Overview Schema Source Related Servers Discussions Admin

Python

Local

ContextSmith

Give your coding agent the right code, not more code.

A local context engine for Claude Code, Cursor, Codex and any MCP agent. It indexes your repository into a code graph, hybrid search and git history, and answers every task with the code that matters, packed into a token budget you choose.

PyPI Python License: MIT

▶ Watch the 60-second video: indexing, context packing, live MCP calls and the benchmark.

Coding agents spend their context window on the wrong code. They grep, open whole files, and run out of room before they reach the function that needs the fix, and you pay for every token they read. ContextSmith answers one question as well as possible: given this task and N tokens, what code should the agent read?

Measured on 114 Django issues from SWE-bench Lite that no tuning step ever saw. Method and full results.

Quickstart (60 seconds)

pipx install "contextsmith[semantic]"      # or: pip install "contextsmith[semantic]"
cd your-repo
ctxsmith index                              # once; afterwards only changed files are re-read
ctxsmith context "Coupons are applied twice at checkout" --budget 4000

Connect it to your agent (the command prints the exact line for your machine):

ctxsmith mcp-config claude    # or: cursor, windsurf, codex
claude mcp add contextsmith -- ctxsmith serve --path /path/to/your-repo

From then on the agent calls get_context itself and gets ranked, budgeted code instead of grepping. Without the [semantic] extra everything still works, using keyword search only.

Related MCP server: crux

Who it's for

Developers

Faster, better agent sessions on big repos. The agent starts from the right functions instead of exploring; fewer wrong edits and "I couldn't find it" loops.
Understand unfamiliar code. ctxsmith context "where are payment retries handled?" returns the relevant functions with their file and line numbers.
Change safely. ctxsmith impact charge_card lists everything that calls it, transitively: what a change could break, before you make it.
Remember the gotchas. ctxsmith note add "never call without the account lock" --symbol charge_card pins a note to the code; it shows up in every future context for that code, for you and for the agent.

Teams and companies

Need	How ContextSmith covers it
Code that must not leave the building (finance, health, government, enterprise IP)	Runs entirely on the developer's machine. Parsing, search and embeddings are local; the only network use is a one-time download of two small open models, which you can mirror internally for air-gapped machines
Predictable AI spend	Every answer has a hard token budget you set, so context cost per task is fixed instead of "whatever the agent opened"
Works with the agents you already pay for	Standard MCP server: Claude Code, Cursor, Windsurf, Codex, Copilot agents and in-house agents use the same index
Onboarding	New engineers and their agents ask questions in plain language and land on the right code
Code review and CI	`ctxsmith context "$PR_TITLE" -b 6000` gives a review bot the code a PR touches and depends on; `ctxsmith impact NAME` shows the blast radius
Team knowledge	Decisions and invariants live next to the code as notes, not in someone's head
No lock-in, no procurement	MIT licence (commercial use is fine), a single SQLite file per repository, no server to run, no account

Typical rollout: each developer installs it with pipx, runs ctxsmith index in the repositories they work on, and adds one MCP line to their agent. There is nothing to host. See Using it at a company for CI and offline setups.

Builders of AI tools

ContextSmith is also a Python library. Use it as the retrieval layer of your own agent, review bot or internal assistant:

from contextsmith import Engine

eng = Engine("path/to/repo")
eng.index()
pack = eng.context("Fix the race when two users book the last seat", budget=6000)
prompt = f"{pack.text}\n\nTask: fix the race when two users book the last seat."

Results

The test: take a real GitHub issue from SWE-bench Lite, check the repository out at the issue's own commit (so no future code or history leaks in), give the issue text to the tool, and check whether the code the real fix changed comes back.

Final test on Django: 114 issues that no tuning step ever saw.

	BM25, whole files	ContextSmith
The fix's file is ranked 1st / in the top 3 / top 5	50.9% / 70.2% / 77.2%	51.8% / 79.8% / 85.1%
The fix's file is inside a 4,000-token context	28.9%	92.1% (3.2x)
The exact lines the fix changes are shown in 4,000 tokens	28.9%	48.1% (1.7x)
Query time (median, laptop CPU, 2,800-file repository)	145 ms	238 ms

The baseline pastes BM25-ranked files whole until the budget runs out, which is what "search the repo and open files" agents do. ContextSmith spends the same tokens on the functions that matter and outlines of the rest, so the right file almost always makes it in.

strategy	R@1	R@3	R@5	R@10	file in 4k	file in 8k	lines in 4k	lines in 8k	ms
BM25, whole files	50.9	70.2	77.2	84.2	28.9	49.1	28.9	49.1	145
lexical (no embeddings)	48.2	74.6	78.9	86.0	86.0	89.5	42.3	46.2	145
embeddings only	48.2	69.3	78.9	86.8	–	–	–	–	249
ContextSmith (default)	51.8	79.8	85.1	88.6	92.1	96.5	48.1	50.7	238
+ cross-encoder re-rank	34.2	73.7	81.6	91.2	–	–	–	–	1824
without git history	56.1	78.9	84.2	90.4	–	–	–	–	249

Full numbers: bench/results-django/summary.md.

What the ablations say, including what didn't work:

Embeddings earn their place: adding them to the lexical ranker lifts top-5 from 79% to 85% and exact-line coverage from 42% to 48%.
The cross-encoder re-rank hurts the top result (52% → 34%) at 8x the latency, so it is off by default and marked experimental. A general web-search re-ranker doesn't understand issue-to-code relevance; a code-trained one is on the roadmap.
Git commit history is mixed: it helped on the tuning repositories, but on Django removing it raises recall@1 by 4 points. It stays on because the default was fixed before the Django run; changing it now would be tuning on the test set.
At 8,000 tokens whole files catch up on exact lines (49% vs 51%): every Django fix here touches one file, and at that budget it often fits whole.

Method. Weights were chosen by grid search on 89 issues from 8 other repositories (pytest, requests, flask, sphinx, pylint, xarray, astropy, seaborn) with bench/tune.py and bench/tune_pack.py, then frozen before Django was run once. Reproduce it with ctxsmith bench --repos django/django (first run: about two hours on a laptop).

How it works

flowchart LR
    subgraph Index["ctxsmith index (incremental)"]
        TS["tree-sitter<br/>7 languages"] --> SYM["symbols · calls · imports"]
        SYM --> G["call graph<br/>PageRank"]
        SYM --> FTS["FTS5 BM25<br/>files · symbols · bodies"]
        SYM --> EMB["ONNX embeddings<br/>symbol summaries"]
        EMB --> VEC["sqlite-vec<br/>cosine index"]
        GIT["git log"] --> H["commit-message index<br/>co-change pairs"]
    end
    subgraph Query["get_context(task, budget)"]
        Q["task text"] --> S1["file BM25"] & S2["semantic kNN"] & S3["paths in task"] & S4["history BM25"]
        S1 & S2 & S3 & S4 --> RRF["reciprocal-rank<br/>fusion"]
        RRF --> KS["knapsack packer<br/>value per token"]
        KS --> OUT["≤ N tokens of code"]
    end
    Index -. one SQLite file .-> Query

One SQLite file per repository holds everything: files, symbols, call and import edges, three FTS5 indexes, git statistics, team notes, and the vector index (a vec0 virtual table from sqlite-vec; a numpy fallback runs where SQLite can't load extensions).

Retrieval (RAG). Each signal produces its own ranked list of files; reciprocal-rank fusion combines them, so no single noisy signal dominates:

Signal	What it catches
BM25 over whole files (`camelCase`/`snake_case` split, paths weighted up)	exact vocabulary
Semantic kNN over symbol summaries (`BAAI/bge-small-en-v1.5`, ONNX, CPU)	the same idea in different words
Paths named in the task (tracebacks, "in `foo/bar.py`")	explicit pointers
BM25 over each file's commit messages	"this was touched for a similar bug before"
Co-change, call-graph neighbours, PageRank, exact-name mentions	available as weights; off by default because the benchmark showed they hurt file ranking

The weights come from a grid search (bench/tune.py) on 89 SWE-bench Lite issues from 8 repositories and were then checked on Django, which tuning never saw.

What gets embedded, and why. Not whole files and not raw chunks: one short summary per function or class — path, qualified name, signature, first docstring sentence. On a laptop CPU this is ~30x cheaper than embedding bodies, and it is what identifies "which function is this about". Vectors are cached by content hash, so a function that didn't change is never embedded twice — across re-indexes and across git checkouts. Test files are skipped.

Experimental re-rank. ctxsmith context --rerank re-scores the top 20 files with a cross-encoder (ms-marco-MiniLM-L-6-v2). It is off by default because the benchmark shows it hurts (see Results).

Packing. Candidates are function bodies (matched by name, docstring and body text), class outlines and file outlines. A greedy knapsack takes the best value per token, discounts repeats from one file, and enforces the budget on the final rendered text, so the answer is never over budget.

Always fresh. Re-indexing compares file size and mtime before reading anything and only re-parses and re-embeds what changed; checking an unchanged 2,800-file repository takes about half a second. The MCP server does this before answering (at most every 2 seconds), so the agent never reads code it has just edited from a stale index.

Use it from your agent (MCP)

ctxsmith mcp-config <client> prints the exact snippet for your machine.

Claude Code

claude mcp add contextsmith -- ctxsmith serve --path /path/to/repo

No install, with uv (the server indexes the folder the agent opens):

claude mcp add contextsmith -- uvx --from "contextsmith[semantic]" contextsmith

Cursor, Windsurf and other clients (mcp.json):

{
  "mcpServers": {
    "contextsmith": { "command": "ctxsmith", "args": ["serve", "--path", "/path/to/repo"] }
  }
}

Codex (~/.codex/config.toml):

[mcp_servers.contextsmith]
command = "ctxsmith"
args = ["serve", "--path", "/path/to/repo"]

Tool	Returns
`get_context(task, budget_tokens)`	the best code for the task, packed to the budget
`search(query)`	ranked functions and classes
`find_symbol(name)`	where something is defined
`callers(name)` / `callees(name)`	one hop of the call graph
`impact(name)`	everything that transitively calls it: what a change could break
`related_files(path)`	files linked by code, and files that change together in git
`add_note(text, path, symbol)`	a decision or gotcha that later sessions should know
`overview()`	languages, size, central and most-changed files
`reindex()`	force an incremental re-index

CLI

Command	What it does
`ctxsmith index [PATH] [--no-semantic]`	Index; incremental, embeddings on when the extra is installed
`ctxsmith context "task" -b 4000`	Best context within a token budget
`ctxsmith rank "task"`	Ranked files, with the signals that found each
`ctxsmith search "query"`	Ranked functions and classes
`ctxsmith symbol / callers / callees NAME`	Navigate the call graph (`--json` for scripts)
`ctxsmith impact NAME`	What could break if NAME changes
`ctxsmith related FILE`	Files linked by code, and files that change together
`ctxsmith note add "text" --file F`	Remember a decision or gotcha
`ctxsmith overview`	Languages, size, central and most-changed files, semantic status
`ctxsmith serve`	MCP server over stdio
`ctxsmith mcp-config [claude\|cursor\|codex]`	Setup snippet for your agent
`ctxsmith bench --repos django/django`	Run the SWE-bench Lite benchmark yourself

Python API

from contextsmith import Engine

eng = Engine("path/to/repo")       # index stored in path/to/repo/.contextsmith/
eng.index()                        # incremental; returns counts and timings
pack = eng.context("Fix the race when two users book the last seat", budget=6000)
pack.text, pack.tokens, pack.files, pack.spans   # markdown, size, files, line ranges shown

eng.rank("seat double-booked").files  # ranked files, with the signals that found each
eng.search("seat reservation")     # ranked functions and classes
eng.impact("reserve_seat")         # transitive callers
eng.related_files("booking/models.py")
eng.add_note("Seats are locked per show, not per seat", path="booking/models.py")

Configuration

Variable	Default
`CTXSMITH_EMBED_MODEL`	`BAAI/bge-small-en-v1.5` (any fastembed text model, e.g. `jinaai/jina-embeddings-v2-base-code`)
`CTXSMITH_RERANK_MODEL`	`Xenova/ms-marco-MiniLM-L-6-v2`
`FASTEMBED_CACHE_PATH`	`~/.cache/contextsmith/models`

The index lives in <repo>/.contextsmith/ (git-ignored automatically). Without the semantic extra everything still works, lexically.

Using it at a company

Per developer (the usual rollout). pipx install "contextsmith[semantic]", then ctxsmith index in each repository and one ctxsmith mcp-config line per agent. Nothing to host, no accounts, no shared service to secure.

In CI: give a review bot the code a pull request is about.

# .github/workflows/pr-context.yml
name: PR context
on: pull_request
jobs:
  context:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }            # full history powers the git signals
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - uses: actions/cache@v4               # reuse the index and the model between runs
        with:
          path: |
            .contextsmith
            ~/.cache/contextsmith/models
          key: contextsmith-${{ github.base_ref }}
      - run: pip install "contextsmith[semantic]" && ctxsmith index
      - run: ctxsmith context "$TITLE" --budget 6000 > pr-context.md
        env:
          TITLE: ${{ github.event.pull_request.title }}   # via env, never inline: no injection
      - uses: actions/upload-artifact@v4
        with: { name: pr-context, path: pr-context.md }

Feed pr-context.md to whichever review model you use, or post ctxsmith impact <function> output as a comment so reviewers see the blast radius.

Offline and air-gapped machines.

# on a machine with internet access (same OS and Python version as the target)
pip download "contextsmith[semantic]" -d wheels
ctxsmith index                     # downloads the embedding model (65 MB) once
# copy wheels/ and ~/.cache/contextsmith/models/ across, then on the offline machine:
pip install --no-index --find-links wheels "contextsmith[semantic]"
export HF_HUB_OFFLINE=1            # never try the network again

What is stored, and where. One SQLite file per repository in <repo>/.contextsmith/: symbols, search indexes, call graph, git statistics and commit messages, notes, and embedding vectors. It is git-ignored automatically and never uploaded anywhere. ContextSmith has no telemetry; the only downloads are the open embedding model from Hugging Face on first use (none without the semantic extra) and, if you run ctxsmith bench, the public benchmark.

FAQ

Does my code leave my machine? No. Parsing, search, embeddings and the MCP server all run locally. Your agent still sends the context it receives to its own model provider, as it would with any file it reads; ContextSmith just makes that context smaller and more relevant.

How big a repository can it handle? Measured on Django (2,800 files, 38,000 functions and classes) on a laptop CPU: 16 s to build the code graph, search and git index from scratch, about 3.5 minutes to embed everything the first time, 0.2 s per query, 0.5 s to check for changes, 136 MB on disk. After the first run only changed files are re-parsed and re-embedded.

Does it replace my agent's own search? No, it gives it a better starting point. The agent can still open any file; it just starts from the right functions instead of grepping.

Which models does it use? BAAI/bge-small-en-v1.5 for embeddings (ONNX, CPU, 65 MB), changeable with CTXSMITH_EMBED_MODEL. No large language model is involved: ContextSmith retrieves, your agent reasons.

What does it cost? Nothing. MIT licence, including commercial use.

Is it production-ready? It is v0.1: tested on Windows, macOS and Linux with Python 3.11–3.13, benchmarked in public, and honest about what doesn't work yet (see Results). Issues and pull requests are welcome.

Languages

Python, JavaScript, TypeScript/TSX, Java, Go and Rust, parsed with tree-sitter.

How it compares

Graphify, codebase-memory-mcp, GitNexus, Serena and Claude Context are good tools; this is where ContextSmith differs:

	ContextSmith
Answers "the best context for this task in N tokens"	✅ budgeted packer, never over budget
Published, reproducible benchmark with baselines and ablations	✅ `ctxsmith bench`, held-out repositories
Lexical + semantic + git history, fused	✅
Fully local, no API keys, one SQLite file	✅
Team notes pinned to code, surfaced in context	✅
Commercial-friendly licence	✅ MIT

Roadmap

Multi-repo indexes, note staleness tracking, a file watcher, a graph view, a PR impact report, and more languages. Ideas and benchmark-backed pull requests are welcome: see CONTRIBUTING.md.

Licence

MIT

Available Tools

10 tools

add_noteC

Remember a decision, invariant or gotcha, optionally pinned to a file or symbol.

Name	Required	Description	Default
`path`	No
`text`	Yes
`symbol`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that notes are pin-able to a file or symbol, but says nothing about persistence scope (private vs shared), whether notes are durable or session-limited, or what the returned result contains.

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

Conciseness4/5

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

A single, tight sentence with the core action and the optionality of pinning front-loaded. No filler; every clause carries information.

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

Completeness3/5

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

The presence of an output schema means return values needn't be explained, and the description covers the core intent plus the optional pinning. However, for a mutation tool with no annotations and undocumented params, it leaves meaningful gaps about persistence behavior and targeted use.

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 0%, so the description must compensate. 'Optionally pinned to a file or symbol' gives meaning to the path and symbol parameters, and 'remember a decision, invariant or gotcha' implies the text parameter's content, but no format details or defaults are clarified.

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?

States a specific action (remember/storing) on a specific resource (a note) and names the kind of content it captures (decisions, invariants, gotchas). It implicitly contrasts with the retrieval-focused siblings like search and get_context, though it doesn't name them explicitly.

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

Usage Guidelines2/5

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

The description gives no explicit when-to-use or when-not guidance, nor does it point to alternatives. An agent must infer from 'remember a decision' that this is the tool for persisting durable context, with no exclusions or routing conditions stated.

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

calleesC

Functions that name calls.

Name	Required	Description	Default
`name`	Yes
`limit`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: not whether the graph is static or runtime, not how unresolved/ambiguous names behave, not that `limit` truncates results, and not any ordering. Only the bare directional semantics are conveyed.

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

Conciseness4/5

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

A single front-loaded sentence with no padding, but it is under-specified rather than efficiently concise — the terseness is a symptom of missing information, not disciplined editing.

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

Completeness2/5

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

An output schema exists, so return shape needn't be explained, but with zero annotation coverage and zero parameter description coverage the description should compensate and does not. An agent knows the direction of the query but not enough to call it confidently on unusual inputs.

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

Parameters2/5

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

Schema description coverage is 0%, so both parameters are undocumented in the schema. The description hints that `name` identifies the caller function, which is genuinely useful, but says nothing about `limit` (default 50, truncation behavior) or what forms `name` accepts (qualified name, file path, symbol ID).

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?

States a specific result set (functions) and the relationship (called by `name`), which implicitly separates it from the sibling `callers` (reverse direction). It never names the sibling or uses an explicit verb like 'list' or 'return', so it stops short of a 5.

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

Usage Guidelines1/5

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

No guidance at all on when to use this versus `callers`, `find_symbol`, `impact`, or `get_context`. The agent must infer directionality and suitability entirely from a six-word fragment.

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

callersC

Functions that call name.

Name	Required	Description	Default
`name`	Yes
`limit`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full disclosure burden. It never says whether the lookup is read-only, whether callers are direct only or transitive, whether `limit` truncates results, or what the result set looks like, so behavior is largely opaque.

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

Conciseness3/5

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

It is a single short fragment with no padding, but it is under-specified rather than tightly written — nothing extra, but nothing front-loaded beyond the bare relationship.

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

Completeness2/5

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

An output schema exists so return shape needn't be described, but for a 2-parameter graph query with zero annotation and zero schema coverage, the description should at minimum define `name` and explain `limit`. Those gaps leave the tool not fully usable from the description alone.

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

Parameters1/5

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

Schema coverage is 0% and the description only echoes the token `name` without defining it (function symbol? file path? qualified name?). The `limit` parameter with its default of 50 is not mentioned at all in the description.

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

Purpose3/5

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

The description states the resource relation — functions that call `name` — which is more than a restatement of the tool name. But it uses no verb, gives no scope (direct vs transitive callers), and never contrasts itself with the sibling `callees`, which is the natural confusion point.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of `callees`/`impact` as alternatives for related questions. The agent must infer that this is the reverse-direction edge lookup.

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

find_symbolB

Where a function, class or method is defined (by name or qualified name), with its signature.

Name	Required	Description	Default
`name`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It mentions returning a location and signature, but does not state behavior for missing symbols, multiple matches, exact versus fuzzy matching, case sensitivity, or supported languages.

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?

The description is a single front-loaded sentence with no redundant or filler content. Every phrase contributes to identifying the symbol definition and its signature.

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

Completeness3/5

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

The tool is simple and has an output schema, so the description need not explain return values in detail. Still, for a lookup tool with no annotations and an undocumented parameter, the description leaves important operational details such as matching semantics and no-result behavior unstated.

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?

The single parameter has 0% schema description coverage, so the description adds useful meaning by saying the input can be a name or qualified name. However, it does not clarify matching rules, formatting examples, or whether partial names are accepted.

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 states a specific lookup purpose: finding where a function, class, or method is defined and returning its signature. It is clearly distinguishable from mutation tools such as add_note or reindex, but it does not explicitly differentiate itself from siblings like search or get_context.

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

Usage Guidelines2/5

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

The description explains what the tool returns but gives no guidance on when to use it instead of alternatives. With siblings such as search, get_context, callers, and callees present, an agent must infer whether find_symbol is for exact name lookup versus broader search or context retrieval.

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

get_contextA

The most relevant code for a task, packed into at most budget_tokens tokens.

Pass the task in plain words (a bug report, a feature request, a stack trace). Files are
ranked by full-text match, meaning (local embeddings), names and paths the task mentions
and git history; function bodies and outlines are then fitted into the budget.

Name	Required	Description	Default
`task`	Yes
`budget_tokens`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the ranking signals (full-text, local embeddings, mentioned names/paths, git history) and that function bodies and outlines are fitted into the budget. It omits cost/latency implications of embedding-based ranking and any failure behavior.

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?

Two short paragraphs, the core promise front-loaded in the first line, then the input guidance and ranking mechanics. Every sentence carries information; nothing is redundant.

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?

An output schema exists so return shape needn't be explained, and the description covers the essential mechanics of ranking and budgeting. It is slightly incomplete on performance characteristics and budget edge cases, but nothing essential to correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate, and it does for both parameters: `task` is explained with concrete examples and `budget_tokens` is given real meaning as the cap on packed tokens. It does not discuss the trade-off of a larger budget or what happens when the budget is very small.

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?

States a specific verb ('packed into') and resource ('the most relevant code for a task'), and the token-budget scope makes it distinguishable from simple lookups. It does not explicitly contrast with sibling tools like search or find_symbol, so differentiation is implied rather than stated.

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

Usage Guidelines3/5

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

The instruction to pass the task 'in plain words (a bug report, a feature request, a stack trace)' gives useful input guidance and implies when the tool fits. There is no explicit when-not or comparison to the sibling search/find_symbol tools, leaving alternative selection to inference.

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

impactB

Everything that transitively calls name: what a change to it could break.

One line per caller, `depth  path:lines  name (kind)`, nearest first.

Name	Required	Description	Default
`name`	Yes
`depth`	No
`limit`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does add useful behavior: one line per caller, nearest first, with the output line format spelled out. It says nothing about whether `limit` truncates results, whether depth bounds the traversal, or whether the tool is purely read-only (only inferable from the subject matter).

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

Conciseness4/5

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

Two short, front-loaded lines with no filler; the blast-radius framing leads and the output format follows. Efficient, though the terseness is part of why parameter semantics go uncovered.

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

Completeness3/5

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 needn't be explained, yet the description still usefully sketches the line format. However, for a 3-param graph tool with zero annotation and zero schema-description coverage, the absence of limit/truncation behavior and of routing versus `callers`/`callees` leaves real gaps.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It explains `name` (the symbol analyzed) and shows `depth` in the output format, but never explains that depth bounds traversal or what its default of 3 means, and `limit` is entirely unmentioned.

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?

States a specific verb+resource: it returns everything that transitively calls `name`, i.e. the reverse-dependency closure. The word "transitively" implicitly separates it from the sibling `callers`, though it never names that sibling, so an agent must infer the distinction.

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

Usage Guidelines3/5

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

"What a change to it could break" implies the use case (pre-refactor blast-radius check), but there is no explicit when-to-use statement and no named alternative such as `callers` for direct-only callers or `callees` for the opposite direction. Usage is only implied.

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

overviewB

Repository summary: languages, size, most central and most changed files.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only summary but says nothing about cost or latency, whether it requires a prior reindex, whether vendored or generated files are excluded, or whether the result can be stale.

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?

A single front-loaded sentence with no filler; every clause names a distinct piece of returned content. There is no redundancy to trim.

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

Completeness3/5

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 with zero parameters the calling surface is trivial. What is missing is the operational context: whether an index must exist first and how this differs from get_context, both of which an agent needs to choose correctly.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter guidance is needed or missing.

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 states a specific resource (repository summary) and enumerates the exact contents: languages, size, central files, and changed files. This is concrete enough to distinguish it from list/query siblings, though it never explicitly contrasts itself with get_context, which could plausibly also return repository-level information.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no named alternative. An agent must infer from the noun 'summary' that this is an orientation or first-call tool and that get_context serves a different purpose.

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

reindexB

Re-index changed files (incremental and fast).

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. "Incremental and fast" hints that only changed files are touched and cost is low, but it does not say whether the call blocks, how long it may take on large change sets, whether it is safe/idempotent, or what permissions it needs.

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

Conciseness4/5

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

A single short sentence with the operation and the key qualifier front-loaded and no filler. It is efficient, though the terseness leaves little room for the guidance the definition lacks elsewhere.

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

Completeness3/5

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

A param-free tool with an output schema means return values need not be explained, and the description covers the core action. Still missing is the operational context an agent needs: scope (whole repo vs. workspace), whether other tools depend on a fresh index, and whether the call is safe to repeat.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate at the parameter level, and the schema is fully self-describing here.

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?

Names a specific operation (re-index) and resource (changed files), plus the execution mode. It is clearly a maintenance action distinct from the query-oriented siblings (search, get_context, find_symbol), though that distinction comes from the verb rather than explicit contrasting language.

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

Usage Guidelines3/5

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

"Changed files" implies the trigger is stale or edited files, so the usage context is inferable. However, the description never states when an agent should call this rather than relying on an already-fresh index, nor whether indexing happens automatically.

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

related_filesB

Files linked to path by imports/calls, and files that historically change with it.

Name	Required	Description	Default
`path`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It does add real behavioral content by revealing that results combine static dependency edges (imports/calls) with historical co-change data — a non-obvious trait. It does not disclose depth, recursion, result limits, or whether the historical signal requires repository history, leaving key behaviors unknown.

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

Conciseness4/5

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

One sentence, front-loaded with the primary signal and no waste. The trailing phrase 'historically change with it' is slightly vague but earns its place by signaling the second data source.

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

Completeness3/5

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 no explanation, and the core concept is conveyed. However, for a tool sitting in a cluster of overlapping relationship tools, the absence of differentiation and parameter-format detail leaves the agent without enough to invoke it confidently over alternatives.

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 description coverage is 0%, so the single `path` parameter is undocumented structurally. The description implies `path` identifies the source file whose relatives are computed, but never specifies absolute vs. relative form, whether directories are accepted, or how paths are interpreted.

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 states a specific resource (files linked to `path`) and two retrieval signals: imports/calls and historical co-change. This distinguishes it from a generic search, though it stops short of naming how it differs from the closely related `callers`, `callees`, or `impact` siblings.

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

Usage Guidelines2/5

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

There is no guidance on when to use this rather than `callers`, `callees`, or `impact`, which all return related-file information from different angles. The agent must infer the selection rule from the one-line description alone.

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

searchB

Ranked symbols (functions, classes, methods) matching a query, as path:lines name (kind).

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

Without annotations, the description must carry the full behavioral burden. It discloses the ranking behavior and output format, which is useful context beyond a bare statement. However, it omits search scope, case sensitivity, behavior on no matches, and any safety or permission details, leaving significant gaps.

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?

A single sentence that is front-loaded with the key information and contains no wasted words. It efficiently conveys the tool's core purpose and output shape.

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

Completeness3/5

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, though the description does provide a format hint. Given the lack of annotations and zero schema description coverage, the description should do more to explain parameters and usage, but it remains minimally adequate for a simple search tool.

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

Parameters2/5

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

Schema description coverage is 0%, so the schema provides no meaning for the two parameters. The description only implies that `query` is used for matching symbols and says nothing about the `limit` parameter's effect or the query syntax. It does not compensate for the coverage gap.

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 states a specific verb (ranked symbols) and resource (functions, classes, methods matching a query), with an output format example. It does not explicitly differentiate from the sibling `find_symbol`, which likely performs a similar function, so it falls short of a 5.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like `find_symbol` or `get_context`, nor any mention of prerequisites or exclusions. The description merely states what the tool returns, leaving usage entirely inferred.

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.

10 tool updatesv0.1.0Oct 25, 2026
- First observedadd_note
- First observedcallees
- First observedcallers
- First observedfind_symbol
- First observedget_context
- First observedimpact
- First observedoverview
- First observedreindex
- First observedrelated_files
- First observedsearch

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.2/5.0

Scored 2026-10-25 16:00 across 10 tools

Disambiguation5/5

Each tool targets a distinct code-context workflow: task packing, symbol search, definition lookup, direct call graph edges, transitive impact, related files, notes, repo overview, and reindexing. Even the closest pairs (search vs. find_symbol, callers vs. impact) are clearly separated by description.

Naming Consistency3/5

Names are readable and uniformly lowercase snake_case, but the conventions are mixed: some are verb_noun (get_context, find_symbol, add_note) while others are bare nouns (search, callers, callees, impact, overview). There is no single predictable verb_noun pattern throughout.

Tool Count5/5

Ten tools is a well-scoped set for a code context and navigation server. Each tool covers a distinct capability needed for task-oriented exploration without obvious padding.

Completeness4/5

The core navigation surface is strong: task-based context, search, definitions, callers/callees, impact, related files, overview, and reindexing. Minor gaps remain around notes lifecycle (add_note exists but no list/get/update/delete notes) and direct file reading, though agents can often work around these via get_context and search.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

GraphifyOAuth
io.github.Graphify-Labs
Search indexed code, trace dependencies, assess change impact, and recall repository memory.
Code Analysis Knowledge & Memory
1
https://api.graphify.com/mcp
TeamShared C
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
1991
https://teamshared.com/mcp
Maguyva
ai.maguyva
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code Analysis Coding Agents
23
https://maguyva.tools/mcp
developer-tools-mcp-server A
com.thenextgennexus
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Developer Tools Search
3
https://nexgendata-mcp-proxy.steve-corbeil.workers.dev/developer-tools-mcp-server/mcp

Related MCP Servers

io.github.pmgarg/cgraphy
Code Analysis Knowledge & Memory RAG Systems
pmgarg
A
license
Not graded
quality
C
maintenance
Enables AI coding agents to query a codebase as a knowledge graph, providing token-budgeted context, search, and impact analysis via MCP tools.
Updated 3 months ago (2026-07-18 04:21 UTC)
33 PyPI
MIT
crux
Code Analysis Search Developer Tools
notshekhar
F
license
Not graded
quality
C
maintenance
Provides a local-first code indexing and search engine for coding agents via MCP, enabling precise codebase queries, symbol lookup, and freshness-aware retrieval.
Updated 3 months ago (2026-08-01 12:28 UTC)
-
codememory
Code Analysis Knowledge & Memory Software Architecture
EldrexDelosReyesBula
A
license
Not graded
quality
B
maintenance
Enables AI agents to locally search, query, and understand codebases with token-efficient context, dependency graphs, history, architecture diagrams, and metrics through MCP.
Updated 2 months ago (2026-09-03 13:32 UTC)
15 npm
3
MIT
@centr-ai/mcp
Code Analysis Knowledge & Memory RAG Systems
chiragpgauswami
A
license
Not graded
quality
B
maintenance
Enables AI coding agents to retrieve token-budgeted project context, search code symbols, look up definitions, and access project memory and cross-project learnings through local MCP tools. It reduces redundant exploration by supplying the smallest useful context from a deterministic, local-first index.
Updated 2 months ago (2026-09-05 16:31 UTC)
MIT