This server (CodeScry) indexes committed code from local git repositories into a SQLite database and exposes ranked code search capabilities to coding agents via four tools:
search_code: Search indexed code using a natural language or keyword query, returning ranked snippets with file locations. Supports filtering by repository, programming language, and path prefix, with a configurable number of results (default 10).
get_symbol: Look up a specific named symbol (e.g., function, class, or method) from indexed metadata, with automatic fallback to full search if not found directly. Optionally scoped to a specific repository.
list_repos: List all indexed repositories along with their freshness/staleness state, so you can see what codebases are available and how up-to-date the index is.
reindex: Trigger a reindex of a repository to refresh the code index after new commits. The repository path is optional when only one repo is indexed.
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., "@repo-index-mcp where is request retry handled"
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.
CodeScry is a local codebase retrieval tool for coding agents. It indexes committed code from local git repos into a local SQLite database, then exposes ranked snippets through a CLI and MCP stdio server.
Local-first by default: auto-selects local Ollama mxbai-embed-large when available, otherwise falls back to hash embeddings and SQLite storage.
Agent-ready: MCP tools for search_code, get_symbol, list_repos, and reindex.
Large-index aware: bounded sqlite-vec candidate paths avoid scoring every chunk once vectors are backfilled.
Semantic opt-in: Ollama, OpenAI, and sentence-transformers providers are available when quality matters more than default speed.
Measured on real repos: public agent-natural evals and ranking/performance findings live in docs/ranking-experiment-findings.md.
Recent private ~/code mxbai eval improved from ~20.7s average query latency to ~1.8s after filtered vector serving optimizations, with Recall@10 stable at 0.800. See docs/performance.md for knobs and diagnostics.
Related MCP server: code-index
Fast path:
curl -LsSf https://raw.githubusercontent.com/Zhachory1/codescry/main/scripts/install.sh | shThe installer uses uv tool install codescry when uv is available, otherwise pipx install codescry. If neither uv nor pipx is installed, it bootstraps pipx with python3 -m pip --user.
If you prefer explicit installs:
pipx install codescry
# or, if uv is already installed
uv tool install codescryNode users can run the npm wrapper after installing uv:
npx codescry doctorThe npm package is a thin wrapper around the Python package. It does not bundle local SQLite index data.
For development:
python -m venv .venv
source .venv/bin/activate
pip install -e '.[dev]'Check local readiness:
codescry doctorFor a deterministic five-minute smoke test, see docs/getting-started.md.
Index this repo or another local git repo:
codescry index /path/to/git/repoQuery it:
codescry query "where is request retry handled" -k 5Lookup a symbol:
codescry get-symbol RepoIndex --repo /path/to/git/repoDiscover and index every git repo under a root:
codescry index-root ~/codeShow indexed repos, stale/dirty state, and CodeScry hook coverage:
codescry statusRun the MCP server over stdio:
codescry serveThe MCP server answers queries only. It is not a file watcher; keep committed-code freshness by running codescry reindex or installing git hooks.
Agent config example:
{
"mcpServers": {
"codescry": {
"type": "stdio",
"command": "/Users/YOU/.local/bin/codescry",
"args": ["--db", "/Users/YOU/.codescry/index.sqlite", "serve"],
"env": {}
}
}
}npm/npx config example:
{
"mcpServers": {
"codescry": {
"type": "stdio",
"command": "npx",
"args": ["-y", "codescry", "--db", "/Users/YOU/.codescry/index.sqlite", "serve"],
"env": {}
}
}
}Use which codescry to find the absolute command path for your machine when using direct CLI installs.
Install hooks for one repo or a repo root:
codescry install-hooks /path/to/git/repo
codescry install-hooks ~/code --recursiveHooks run best-effort after commit/merge:
codescry --db <db> reindex "$PWD"They preserve the selected DB path and must not fail git commands.
If hooks are not practical, run an opt-in committed-state watcher:
codescry watch ~/code/my-repo
codescry watch --once --jsonlThe watcher polls git HEAD for indexed repos or a specified repo, then reindexes committed snapshots only when the commit changes.
docs/getting-started.md — install to first useful query.
docs/mcp-clients.md — MCP config examples.
docs/troubleshooting.md — common setup/query/freshness issues.
docs/cli-reference.md — command reference.
docs/output-schema.md — JSON fields.
docs/evals.md — eval authoring and gate.
docs/performance.md — query/index latency knobs, candidate union, batching, and debug telemetry.
docs/embedding-providers.md — hash, Ollama, OpenAI, and sentence-transformers embedding providers.
docs/pilot.md — 5-engineer pilot measurement plan and local reporting commands.
docs/language-support.md — parser/regex/window support matrix.
docs/recipes.md — common operations.
docs/upgrade-uninstall.md — lifecycle commands.
docs/release.md — PyPI-first and npm-wrapper release flow.
docs/ranking-experiment-findings.md — retrieval/ranking experiments and eval findings.
The seed golden set lives in evals/golden.codescry.jsonl.
Run the eval gate:
codescry eval evals/golden.codescry.jsonl . -k 10 --fail-under 0.85Pilot task/activation/miss events are recorded in ~/.codescry/usage.jsonl without snippets. Passive query logging is opt-in with CODESCRY_ENABLE_USAGE_LOG=1. Use:
codescry pilot reportSee docs/pilot.md for activation, timing, miss capture, and decision gates.
Default auto embeddings use local Ollama mxbai-embed-large when available, otherwise local deterministic hash vectors.
Optional embedding providers include Ollama, OpenAI, and sentence-transformers. See docs/embedding-providers.md.
Changing embedding provider or model requires reindexing because stored vectors are model-specific.
Python functions/classes/methods get parser-backed symbol metadata.
TS/JS/Go/Java/Rust/C/C++/SQL get Tree-sitter parser-backed symbol metadata.
Other common declaration patterns get regex-backed symbol metadata.
get_symbol uses stored symbol metadata before search fallback.
Search blends vector, lexical, symbol, and path scores.
Results include stale/dirty flags.
Default auto provider does not use hosted APIs. It uses local Ollama if available, otherwise local hash embeddings.
Default configuration does not send source code to hosted external APIs.
OpenAI and non-local Ollama embedding endpoints send chunks and queries outside your machine. See SECURITY.md and docs/embedding-providers.md.
Index data is local SQLite derived data and can be deleted/rebuilt.
Files matching high-confidence secret patterns are skipped and prior chunks for those paths are removed.
Secret skipping is a best-effort local guardrail, not a guarantee. See SECURITY.md.
Python uses stdlib AST parser chunks; TS/JS/Go/Java/Rust/C/C++/SQL use Tree-sitter parser chunks; other languages use regex-backed symbol hints plus line windows.
Default auto embeddings prefer local semantic Ollama when available and fall back to hash embeddings otherwise; hosted semantic embeddings are opt-in only.
SQLite remains the default local store; large-index serving uses bounded sqlite-vec candidate paths where vector coverage exists.
Freshness is committed-code freshness; dirty working-tree edits are reported but not indexed.
Look up a symbol from indexed metadata, falling back to search.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| repo | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and discloses the fallback behavior. However, it omits other behaviors such as what happens on failure, authentication needs, or rate limits. Some transparency is provided, but not 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?
The description is one sentence with no unnecessary words. It front-loads the core action and is appropriately sized for the tool's complexity.
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 has two parameters and no nested objects, the description should at least clarify parameter usage. It fails to do so, and while an output schema exists, the lack of parameter semantics makes it incomplete.
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 0%, yet the description does not explain the parameters 'name' (required) or 'repo' (optional). The user is left to guess their purpose, which is insufficient for effective tool use.
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 looks up a symbol from indexed metadata with a fallback to search. It distinguishes from sibling 'search_code' by implying a direct lookup then fallback. Could be more precise about what 'indexed metadata' means.
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 provides no explicit guidance on when to use this tool versus alternatives like 'search_code' or 'list_repos'. The fallback mention is implicit, but no when-not-to-use or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List indexed repos and freshness state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool lists repos and freshness state, with no mention of side effects, authentication needs, rate limits, or what 'freshness state' entails. This is insufficient for a transparent tool definition.
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 extremely concise—one sentence with clear verb and resource. It is front-loaded and contains no unnecessary words, earning every word's place.
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 (no parameters, output schema exists), the description is mostly complete. However, it could benefit from clarifying 'freshness state' (e.g., last indexed time) or output structure, but the output schema likely covers that. For a list tool, this suffices.
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?
There are no parameters, so the input schema is trivially covered. Per guidelines, 0 params yields a baseline of 4. The description adds no parameter info, but none is needed.
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 indexed repos and their freshness state. The verb 'list' and resource 'indexed repos' are specific. It distinguishes from siblings like 'get_symbol' (lookup a symbol), 'reindex' (trigger indexing), and 'search_code' (search within code), as listing repos is a distinct operation.
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 provides no guidance on when to use this tool versus alternatives. Sibling tools exist (get_symbol, reindex, search_code) but no comparative context is given, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reindex a repo. Path optional only when exactly one repo is indexed.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Reindex a repo' without disclosing behavioral traits such as idempotency, required permissions, or potential side effects. The description does not add enough context beyond the name.
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 extremely concise (one short sentence), which is front-loaded but insufficiently sized to convey necessary details. While concise, it sacrifices completeness for brevity.
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 low schema coverage and no annotations, the description should provide more context about the tool's behavior and output. Although an output schema exists (not shown), the description does not reference it or explain what happens after reindexing.
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 0%, so the description is responsible for explaining parameter meaning. It only mentions that path is optional under a condition, but does not describe what the repo_path value represents or its format, limiting clarity.
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 action (reindex) and the resource (a repo), and adds a condition about when the path parameter is optional. This distinguishes it from sibling tools which handle symbol lookup, repo listing, and code 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?
The description gives a rule for when the path is optional, implying usage context when there is exactly one indexed repo. However, it does not provide guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search indexed code and return ranked snippets with file locations.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| repo | No | ||
| query | Yes | ||
| language | No | ||
| path_prefix | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the output type (ranked snippets with file locations) but omits any mention of side effects, authentication requirements, rate limits, or whether the operation is read-only.
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 10-word sentence, which is concise but lacks substantive detail. It earns its space but could be expanded with key information without becoming verbose.
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 presence of 5 parameters (1 required), 0% schema coverage, and no annotations, the description is insufficiently complete. It does not cover query syntax, result ordering, or filtering options, leaving significant gaps for an agent to correctly invoke the tool.
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?
The input schema has 0% description coverage for its parameters, meaning none are documented in the schema. The tool description fails to explain any parameter (query, k, repo, language, path_prefix), leaving the agent with no semantic guidance beyond parameter names.
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 verb 'search', the resource 'indexed code', and the outcome 'return ranked snippets with file locations'. It effectively distinguishes from sibling tools like 'get_symbol' (which retrieves a single symbol) and 'list_repos' (which lists repositories).
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 provides no guidance on when to use this tool versus alternatives. It does not mention typical use cases, prerequisites, or scenarios where other tools would be preferred.
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.2.9get_symbollist_reposreindexsearch_codeEach tool targets a distinct operation: symbol lookup, repo listing, reindexing, and code search. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (get_symbol, list_repos, reindex, search_code) using snake_case. Naming is predictable.
With 4 tools, the server covers the core operations for an indexed code repository without being bloated. Each tool has a clear role.
The tool set covers symbol lookup, code search, repo listing, and reindexing but lacks tools for adding or removing repos from the index, which is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Zhachory1/codescry'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
