Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@code-context find the definition of the function 'calculate_total'"
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.
Status: stable (v1.0.0). A Python MCP server with local RAG for Claude Code. Implements the
code-contextTool Protocol v1.2 defined bycontext-template.
When you point Claude Code at a repo, you give it CLAUDE.md for static context. code-context adds dynamic context via 7 MCP tools:
search_repo(query, top_k?, scope?) — hybrid retrieval across the codebase: vector embeddings (semantic) fused with BM25 keyword search (exact identifiers) via Reciprocal Rank Fusion. Optional cross-encoder reranking (off by default — enable with CC_RERANK=on).
recent_changes(since?, paths?, max?) — recent git commits, optionally filtered.
get_summary(scope?, path?) — structured project summary (name, stack, key modules, stats).
find_definition(name, language?, max?) — locate where a symbol (function, class, method, type) is defined. Use INSTEAD of Grep for def X / class X / function X patterns. Returns repo-relative paths with line ranges and the symbol's kind (function, class, method, interface, struct, enum, record). For Markdown files, also finds doc sections by heading text (kind = section).
find_references(name, max?) — list every line mentioning a named symbol. Use INSTEAD of grep -n "X" when the user asks "who calls X?" or "where is X used?". Word-boundary matched, so log doesn't return logger.
get_file_tree(path?, max_depth?, include_hidden?) — repo-relative directory tree, gitignore-aware. Use INSTEAD of Bash: ls -R or Bash: tree for orientation prompts ("show me the project structure", "what's in this module?"). Returns hierarchical FileTreeNode with file sizes; honors .gitignore; defaults to depth 4.
explain_diff(ref, max_chunks?) — AST-aligned chunks affected by the diff at ref (full SHA, HEAD, HEAD~N, branch). Use INSTEAD of Bash: git show <sha> for "what does this commit do" questions. The chunker resolves which whole functions/classes were touched, not raw line additions.
Architecture: hexagonal (ports & adapters). 9 driven ports with default implementations (sentence-transformers embeddings, NumPy+Parquet vector store, tree-sitter / line chunker, filesystem code source, git CLI, filesystem introspector, SQLite FTS5 keyword index, cross-encoder reranker, SQLite-backed symbol index). All swappable.
Related MCP server: mcp-deepcontext
pip install code-context-mcp
# or, if you don't want torch (~2 GB), use the OpenAI embeddings backend:
pip install code-context-mcp[openai]The PyPI distribution is
code-context-mcp(the unhyphenatedcode-contextname was squatted by an unrelated, abandoned project from 2023; see CHANGELOG for context). The Python module is stillcode_contextand the CLI binaries are stillcode-contextandcode-context-server, so quickstart commands andfrom code_context import ...are unchanged.
Note: the default install pulls
sentence-transformers+ theall-MiniLM-L6-v2model on first run. Plan for ~2 GB of disk after first reindex (torch ≈ 2 GB, model ≈ 90 MB). Use the[openai]extra to avoid torch entirely.
cd /path/to/your/repo
claude mcp add code-context --command code-context-server
# Open Claude Code. From v0.9.0 the server starts in <1 s on a previously-indexed
# repo; the first reindex (and any subsequent ones) run on a background thread,
# so queries are never blocked. Cold start: queries return [] until the first
# bg reindex completes (~30-60 s on a typical repo with all-MiniLM on CPU).
# Edit-cycle reindex is sub-10 s thanks to v0.8.0's dirty_set tracking.If you want every save in the repo to flow into the index without
manual code-context reindex:
pip install code-context-mcp[watch] # adds watchdog
export CC_WATCH=on
claude mcp add code-context --command code-context-serverEdits are debounced for ~1 s (configurable via
CC_WATCH_DEBOUNCE_MS) and then trigger a background reindex.
Default off — opt-in.
For OpenAI embeddings:
export CC_EMBEDDINGS=openai
export OPENAI_API_KEY=sk-...
claude mcp add code-context --command code-context-servercode-context auto-detects the best available device for embeddings and cross-encoder rerank:
CUDA: install torch with the CUDA wheels (pip install torch --index-url https://download.pytorch.org/whl/cu121). The first query after a cold start will use GPU automatically. Expect cross-encoder p50 ≤ 100 ms on most consumer GPUs.
Apple Silicon (MPS): detected automatically on macOS with M-series chips. Some sentence-transformers operations are not yet stable on MPS; if the model fails to load, code-context logs a warning and falls back to CPU.
CPU: the default fallback. With v1.5's distilled cross-encoder (MiniLM-L-2-v2), hybrid rerank p50 is ~1.1 s on CPU — usable interactively from Claude Code.
No env var or config flag is required.
If you installed Python from the Microsoft Store (the default in some Windows
SKUs), the OS silently redirects writes from %LOCALAPPDATA% (where
platformdirs places the default cache) to a per-app sandbox under:
%LOCALAPPDATA%\Packages\PythonSoftwareFoundation.Python.3.X_qbz5n2kfra8p0\LocalCache\Local\code-context\This is fine — the index works — but code-context reports the nominal
cache path, not the sandboxed real path. If you can't find the cache where
code-context status prints, look under Packages\...\LocalCache\...
or set CC_CACHE_DIR explicitly to a path outside the sandbox:
$env:CC_CACHE_DIR = "C:\Users\<you>\code-context-cache"To avoid the sandbox entirely, install Python from python.org instead of the Microsoft Store.
Claude Code defaults to its built-in tools (Bash, Grep, Glob, Read) over MCP servers because it knows them best. To get the value of code-context, give Claude an explicit hint by adding a section like this to your project's CLAUDE.md:
## Context tools
This repo has the [code-context](https://github.com/nachogeinfor-ops/code-context) MCP server installed. Prefer it over built-in tools:
- **`search_repo(query, top_k?, scope?)`** — for conceptual questions like "where do we handle authentication" or "how is caching implemented". Use this instead of `Grep` whenever the query isn't an exact string match.
- **`recent_changes(since?, paths?, max?)`** — for "what changed recently" / commit-history questions. Use this instead of shelling out to `git log`.
- **`get_summary(scope?, path?)`** — for project orientation at session start, or to inspect a specific module.
- **`find_definition(name, language?, max?)`** — for "where is X defined?". Use this instead of `Grep` for `def X` / `class X` patterns; tree-sitter-indexed at reindex time, so it's faster and more accurate than scanning text.
- **`find_references(name, max?)`** — for "who calls X?" / "where is X used?". Use this instead of `grep -n`; word-boundary matched so `log` won't match `logger`.
- **`get_file_tree(path?, max_depth?, include_hidden?)`** — for "show me the project structure" / "what's in this module?". Use this instead of `Bash: ls -R` / `Bash: tree`; gitignore-aware and structured (file sizes included).
- **`explain_diff(ref, max_chunks?)`** — for "what does this commit do?" / "what changed in HEAD~3?". Use this instead of `Bash: git show <sha>`; the chunker resolves whole functions/classes that were touched, not raw line additions.Without this hint, Claude will work fine — it just won't reach for the MCP tools, which means the index goes unused. The hint is one paragraph; copy-paste it.
code-context-server is the MCP binary; you don't run it directly. The companion code-context CLI helps administer the index:
code-context status # print index health + dirty/deleted counts
code-context doctor # run env + index health checks (no side effects)
code-context reindex # incremental by default (only changed files)
code-context reindex --force # full reindex (post-model-upgrade or cache reset)
code-context query "where do we validate user emails" # debug, no MCP
code-context clear --yes # delete the cache for this repo
code-context refresh # trigger a reindex + wait for swap (since v1.10.0)
code-context cache export --output cache.tar.gz # bundle the active index (since v1.10.0)
code-context cache import cache.tar.gz # restore a bundle (rejects version mismatches; --force overrides)doctor is the first stop when something looks wrong — it surfaces missing
dependencies, an unwritable cache, an absent HF model cache, a corrupted
index, etc., without doing anything destructive. Exit code is 0 if every
check passed, 1 if anything failed.
Configured via env vars. See docs/configuration.md for the full list. Most-used:
Var | Default |
|
|
|
|
|
|
|
|
| platformdirs user cache |
|
|
Since v2.0.6, the default embeddings backend is onnxruntime. The torch
backend remains available for users who need CUDA acceleration or want to
use a model not on the ONNX-supported list.
# Default (fast cold start, CPU-only):
export CC_EMBEDDINGS_BACKEND=onnx # implicit default
# Opt back to torch (slower cold start, supports CUDA/MPS):
export CC_EMBEDDINGS_BACKEND=torchModels with verified ONNX exports in v2.0.6:
Embeddings: all-MiniLM-L6-v2 (default)
Reranker: cross-encoder/ms-marco-MiniLM-L-2-v2 (default)
Other registered models (BAAI/bge-base-en-v1.5, jinaai/jina-embeddings-v2-base-code, nomic-ai/CodeRankEmbed) automatically fall back to torch with an info log when selected under the ONNX backend. code-context doctor shows the active backend.
Telemetry is off by default and always opt-in. On your first
run against a new repo, the CLI (code-context query/reindex/status)
asks once whether to enable it; your answer is persisted in the
per-repo cache and respected on subsequent runs. Non-interactive
callers (piped CLI, MCP stdio server) never prompt and default to
off — set CC_TELEMETRY=on explicitly to opt in for those.
What's collected when enabled: a weekly heartbeat and session
aggregates to PostHog Cloud. Never PII, query text, code content,
repo paths, file names, or IPs. See docs/telemetry.md
for the full schema, what's not collected, and how the anonymous
install ID is derived.
CC_TELEMETRY env var always overrides the per-repo marker.
Public API (v1) — what's stable; what's not. Read this before depending on code-context from another project.
Configuration — every env var with examples (chunker strategies, hybrid search, symbol index, background reindex, watch mode, …).
Architecture — hexagonal diagram, port contracts, indexing lifecycle, Sprint 7 background-thread + bus.
Eval suite — NDCG@10 / MRR / latency baselines per retrieval mode.
Releasing — Trusted Publisher setup, per-release checklist.
Extending — write your own embeddings provider, vector store, or chunker.
v1.0.0 — stable. Public surface frozen; v1.x will only add. See
docs/v1-api.md for the commitment scope and
CHANGELOG.md for what shipped in each version.
MIT.
AST-aligned chunks affected by the diff at ref. Use INSTEAD of Bash: git show <sha> when the user asks "what does this commit do?" or "what changed in HEAD~3?". The chunker resolves which whole functions / classes were touched, not just raw line additions — much easier for an LLM to reason about. Returns DiffChunk[] with path, lines, snippet, kind, and change ("added"|"modified"|"deleted").
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Git ref: full SHA, short SHA, HEAD, HEAD~N, branch name. | |
| max_chunks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that chunks are AST-aligned (not raw lines), and lists the return fields (path, lines, snippet, kind, change). No hidden behaviors omitted.
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 with no redundancy. Each sentence serves a distinct purpose: purpose, usage, advantage, output. Front-loaded with key information.
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?
Given no output schema and only 2 params, the description covers most key aspects: what it returns, when to use, and a core differentiator (AST chunking). Could mention pagination or error cases but not necessary for basic use.
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 50% (ref has description, max_chunks has none). Description does not add extra parameter meaning beyond what schema provides, especially for max_chunks. No mention of parameter constraints or defaults.
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 clearly states the tool returns AST-aligned chunks from a diff at a given ref, distinguishing it from sibling tools like search_repo. It explicitly contrasts with git show, providing a specific verb and resource.
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?
Explicitly tells when to use (e.g., 'what does this commit do?') and provides a concrete alternative to avoid ('Bash: git show'). Lacks explicit when-not-to-use cases but gives strong positive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate the definition site of a named symbol (function, class, method, type, struct, enum, interface, record). Use this INSTEAD of shelling out to grep when the user asks "where is X defined?" — returns SymbolDef[] with path, line range, kind, and language. Faster and more accurate than grepping for def X / class X / function X / etc., because it consults a tree-sitter-indexed symbol table built at reindex time, not the raw text.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact identifier to locate. | |
| language | No | Optional language hint for same-name disambiguation. Mirrors the set indexed by the tree-sitter chunker (see EXT_TO_LANG in chunker_treesitter.py). | |
| max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains it consults a tree-sitter-indexed symbol table built at reindex time, and mentions speed and accuracy. However, it does not cover what happens if symbol is not found or error cases.
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?
The description is front-loaded with purpose and usage guidance. It is slightly long but each sentence adds value. Some redundancy in listing symbol types and emphasizing speed.
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?
Given no output schema, the description mentions return type SymbolDef[] with fields. It distinguishes from sibling tool find_references implicitly. Lacks details on return structure but adequate overall.
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 description coverage is 67% (two of three parameters described). The description adds context for the language parameter (disambiguation) but does not describe the max parameter. It provides some value beyond schema.
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 clearly states the tool locates the definition site of a named symbol, listing specific symbol types and mentioning it returns SymbolDef[] with path, line range, kind, and language. It distinguishes from grep by being faster and more accurate.
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?
Explicitly says 'Use this INSTEAD of shelling out to grep' and gives context about the user asking 'where is X defined?'. Explains why it's better than grepping due to tree-sitter indexing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every textual occurrence of a named symbol in the indexed corpus. Use INSTEAD of grep -n "X" when the user asks "who calls X?" or "where is X used?". Returns SymbolRef[] with path, line, snippet. Word-boundary matched, so 'log' won't return 'logger' or 'log_format'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact identifier to find references for. | |
| max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return type (SymbolRef[] with path, line, snippet) and matching behavior (word-boundary matched). Lacks details about limits of the indexed corpus, but adequate given no 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 concise sentences, each serving a distinct purpose: purpose, usage, and behavioral detail. No wasted words.
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?
Covers all essential aspects for a simple tool: purpose, usage, return type, matching details. Sufficient for an agent to select and invoke 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?
Adds word-boundary matching behavior to the name parameter beyond schema description. The max parameter is mentioned in schema only, but description adds context about default.
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 clearly states the tool lists every textual occurrence of a named symbol, using specific verbs and resource. It distinguishes from siblings like find_definition by focusing on references.
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?
Explicitly says to use instead of grep for 'who calls X?' or 'where is X used?', providing clear when-to-use and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repo-relative directory tree, gitignore-aware. Use INSTEAD of shelling out to Bash: ls -R or Bash: tree when the user asks for the project structure or for orientation in an unfamiliar module. Returns a hierarchical FileTreeNode with files (with byte sizes) and directories (with recursive children, capped at max_depth). Honors .gitignore; skips hidden files unless include_hidden=true.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional repo-relative subdirectory; defaults to root. | |
| max_depth | No | Cap on tree depth. | |
| include_hidden | No | Include dot-files / dot-directories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses all key behavioral traits: it returns a hierarchical FileTreeNode with files (byte sizes) and directories (recursive children capped at max_depth), honors .gitignore, and skips hidden files unless include_hidden=true. This fully informs the agent about behavior without relying on 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?
The description is three sentences, each serving a distinct purpose: (1) defines the tool, (2) provides usage guidance, (3) details return structure and behavior. No wasted words, front-loaded with the essential purpose.
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?
For a read-only tree retrieval tool with three parameters, the description covers the return type (FileTreeNode), key behaviors (gitignore-aware, hidden file handling, depth cap), and usage context. No output schema exists, but the description sufficiently explains the result structure.
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?
With 100% schema description coverage, each parameter is already documented in the schema. The description adds value by explaining that path defaults to root, max_depth caps recursion, and include_hidden controls dot-file inclusion. This complements the schema without redundancy.
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 clearly states the tool's function: 'Repo-relative directory tree, gitignore-aware.' It specifies the verb (get) and resource (file tree) and distinguishes itself from sibling tools like search_repo or find by explicitly contrasting with shell commands ls -R and tree.
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?
The description explicitly advises: 'Use INSTEAD of shelling out to Bash: ls -R or Bash: tree when the user asks for the project structure or for orientation in an unfamiliar module.' This provides clear context and an explicit alternative, leaving no ambiguity about when to apply this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured snapshot of the project or a module: name, purpose (README first paragraph), stack (Python/Node/Rust/Go/Java), entry_points, key_modules, stats (files, loc, languages). Useful at session start for orientation; prefer it over reading README/CLAUDE.md when you need machine-readable fields.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| path | No | Required when scope='module'; repo-relative path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description covers the output structure but does not mention any behavioral traits such as read-only nature, side effects, authentication requirements, or performance considerations.
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?
The description is a single sentence that efficiently conveys the tool's purpose and output, followed by a brief usage guideline. Every word is necessary, and there is no redundancy or fluff.
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?
Given the tool's simplicity (two parameters, no output schema, no annotations), the description provides sufficient information about what the tool returns and when to use it. It lists the key output fields, which compensates for the lack of an output schema. However, it could be more explicit about the exact data format.
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 description coverage is 50% (only 'path' has a description). The description does not add any parameter-specific information beyond what the schema already provides. With moderate coverage, the description adds marginal value, thus a baseline score of 3 is appropriate.
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 clearly states that the tool returns a structured snapshot of the project or module, listing specific fields (name, purpose, stack, etc.). It also distinguishes itself from reading README/CLAUDE.md, showing differentiation from potential alternatives.
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?
The description explicitly states when to use this tool (session start for orientation) and when to prefer it over alternatives (reading README/CLAUDE.md for machine-readable fields). However, it does not discuss when not to use it relative to other sibling tools like search_repo or find_definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent git commits with structured fields (sha, ISO date, author, paths, summary). Use INSTEAD of git log shell calls — the output is already parsed and filterable by since and paths. Defaults to the last 7 days when since is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Cutoff for commits. Accepts ISO 8601 ('2026-05-08T00:00:00Z'), relative phrases ('4 hours ago', '2 weeks ago'), or keywords ('yesterday', 'today', 'last week'). Defaults to 7 days ago when omitted. | |
| paths | No | ||
| max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes output fields and parsing, but lacks details on read-only nature, performance characteristics, or error handling. Adequate for a simple query tool.
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?
Two sentences, no fluff. Front-loaded with core result, then usage guidance. Highly efficient.
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?
No output schema or annotations. Description covers what is returned, filtering options, and defaults. Lacks explanation of response structure (e.g., list of commits) but sufficient for agent to choose 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 low (33%). Description adds context for `since` (defaults and examples) and mentions filtering, but does not explain `paths` or `max` beyond schema defaults. Incomplete compensation.
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?
Description clearly states it returns recent git commits with structured fields (sha, ISO date, author, paths, summary). It distinguishes from 'git log' shell calls but does not explicitly differentiate from sibling tools like search_repo or explain_diff.
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?
Explicitly says 'Use INSTEAD of `git log` shell calls' and describes filtering by `since` and `paths`. Defaults mentioned. No explicit when-not-to-use guidance for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a background reindex without restarting the server. Use after large external changes (git checkout, cache import, file restore). By default blocks until the new index is active (60s timeout). Pass wait=false for fire-and-forget, or timeout to extend the wait window for large repos that need more than 60s to reindex.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | When false, return immediately with `{triggered: true}` after firing the reindex; do not block on the swap event. Default true. | |
| timeout | No | Seconds to wait for the swap event when wait=true. Clamped to [1, 600]. Ignored when wait=false. Default 60. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses blocking behavior, timeout, and return shape for wait=false. Lacks details on error handling or failure cases.
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?
Two sentences, zero waste. First sentence states purpose, second provides usage details. Efficient and well-structured.
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?
No output schema, but description mentions return value for wait=false. Could be more complete on error handling and return format for wait=true, but given low complexity, it is fairly complete.
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 baseline is 3. Description adds value by clarifying default behavior of wait, clamping of timeout, and relationship between parameters, improving understanding beyond schema.
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?
Description clearly states the tool triggers a background reindex without restarting, using a specific verb and resource. It distinguishes from sibling tools that deal with code navigation and search.
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?
Explicitly says when to use (after large external changes) and provides guidance on blocking vs. fire-and-forget. However, it does not mention when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search over the indexed codebase. Use this INSTEAD of Grep when the query is conceptual (e.g. 'where do we validate input', 'how is caching implemented', 'authentication flow'). Returns ranked code fragments with file path, line range, snippet, score and a one-line why excerpt. For exact-string lookup, Grep is still better.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| scope | No | Optional repo-relative path prefix to constrain results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields (file path, line range, snippet, score, why excerpt). Lacks details on auth or side effects, but for a search tool this is comprehensive.
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 concise sentences, front-loaded with purpose. Every sentence is informative with no redundancies.
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?
Despite missing annotations and output schema, the description adequately covers purpose, usage, and return format. Could mention indexing requirements, but sufficient for typical use.
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 description coverage is only 33% (only 'scope' described). The tool description does not add meaning for 'query' or 'top_k' beyond the schema, leaving gaps in understanding parameter behavior.
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 clearly states it performs 'semantic search over the indexed codebase', distinguishing it from sibling tools like find_definition and find_references. It uses a specific verb+resource combination and contrasts with Grep.
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?
Explicitly tells when to use (conceptual queries) and when not to (exact-string lookup, where Grep is better), with concrete examples. Provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0explain_difffind_definitionfind_referencesget_file_treeget_summaryrecent_changesrefreshsearch_repoAll 8 tools have clearly distinct purposes, with no overlap. Each tool's description explicitly states when to use it instead of alternatives, making it easy for an agent to select the correct tool.
Tool names consistently use lowercase with underscores, following a verb_noun pattern (e.g., find_definition, get_file_tree, search_repo). The only exception is 'refresh', which is a verb alone but still fits the action-oriented style.
With 8 tools, the server is well-scoped for a code context assistant. Each tool provides essential functionality without redundancy, covering diff analysis, symbol navigation, project structure, git history, and reindexing.
The tool surface comprehensively covers the code context domain: diff explanation, symbol definition/references, file tree, project summary, recent changes, reindexing, and semantic search. No obvious gaps exist for typical code understanding tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
An MCP server that gives your AI access to the source code and docs of all public github repos
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nachogeinfor-ops/code-context'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
