This server provides local code intelligence for AI agents through MCP, letting you index repositories and query structural and semantic code information.
Index a local repository with astra_index_repo, building Astra's graph and vector store.
Search code by intent with astra_semantic_search, finding relevant indexed chunks for natural-language queries.
Find exact callers of a function or method using the structural graph with astra_get_callers.
Get hybrid context with astra_hybrid_context, combining semantic matches with structural graph expansion.
Generate a visualization with astra_visualize, producing a local HTML report and returning its path and file URL.
Provides local code intelligence for AI agents, enabling indexing of repositories into a structural graph and searchable code-chunk index, with tools for semantic search, finding callers, and hybrid context retrieval.
Click on "Deploy 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., "@astra-mcp search my codebase for rate limiting implementation"
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.
Astra is dual-licensed under the MIT License or Apache License 2.0, at your option.
Astra is a local code intelligence service for AI agents. It parses repository files into a structural NetworkX graph and a searchable local code-chunk index, with full Python AST analysis and AST-compatible structural extraction across common source, markup, and configuration formats. The same engine is available through the astra CLI and the official MCP Python SDK.
Astra is designed as a local code intelligence fabric: a deterministic structural layer explains how a codebase is assembled, while a semantic retrieval layer explains what the code means. Both layers feed the same knowledge graph and are exposed through the CLI and MCP so engineers, CI systems, and AI agents operate on one shared model of the repository.
Intelligence layer | What it does | Business value | Primary artifact or interface |
Incremental repository indexing | Recursively inventories supported files, ignores generated/dependency directories, and uses SHA-256 fingerprints to detect additions, edits, and removals. | Keeps repository intelligence current while minimizing repeat processing and update time. |
|
AST structural intelligence | Parses Python with the native AST and extracts declarations, methods, calls, branches, nesting, parameters, and source locations. Other supported formats receive language-aware structural extraction. | Turns source code into inspectable business entities and measurable logic risk without importing or executing the project. | Code chunks and structural references |
Knowledge graph | Builds directed relationships between modules, declarations, callers, dependencies, and definitions using NetworkX. | Makes blast radius, dependency paths, circularity, orphan code, refactor order, and architecture health queryable. |
|
Semantic retrieval | Searches indexed code by concepts, identifiers, docstrings, and source content; hybrid workflows combine semantic matches with graph expansion. | Lets teams find capabilities by intent instead of memorizing filenames or symbol names. |
|
Vector search | Stores code chunks in a local vector index and ranks relevant source for natural-language queries, with deterministic lexical retrieval available by default. | Shortens discovery time when business language and implementation language differ. |
|
Optional neural retrieval | Can use Sentence Transformers and Chroma for embedding-based similarity; the default local lexical path requires no model download. | Adds meaning-based recall while preserving a lightweight offline baseline. | Optional embedding backend |
Risk and impact intelligence | Scores fragility through graph centrality, AST complexity, and coupling; traces upstream blast radius and identifies high-dependency star nodes. | Helps prioritize review and refactoring effort where change risk is highest. |
|
Code-health governance | Aggregates cycles, orphan candidates, fragility, star-node exposure, impact, and test reachability into a CI-ready health decision. | Converts architectural signals into a consistent merge-readiness policy and focused review queue. |
|
Automated testing intelligence | Maps source declarations to tests, selects affected tests, generates reviewed scaffolds, runs targeted pytest, and combines the workflow into one validation command. | Reduces test runtime and agent token usage while preserving evidence for every change. |
|
Agent orchestration | Provides Dipper context scoops, Tether checks, health gates, validation workflows, refactor plans, and the | Gives AI agents a disciplined operating model with evidence before edits and validation after edits. | CLI commands and MCP tools/prompts |
Live delivery surfaces | Serves the same engine through terminal commands, MCP, local HTML visualization, and a continuous filesystem watcher. | Fits developer workstations, CI pipelines, long-running agent sessions, and visual architecture reviews without duplicating logic. |
|
The MCP surface exposes twenty-one tools and one orchestration prompt: astra_index_repo, astra_semantic_search, astra_get_callers, astra_path, astra_dipper, astra_tether, astra_get_fragility_hotspots, astra_star_nodes, astra_impact, astra_refactor_plan, astra_test_map, astra_affected_tests, astra_gen_test_scaffold, astra_run_impacted, astra_validate_change, astra_health_gate, astra_start_watch, astra_index_status, astra_stop_watch, astra_hybrid_context, and astra_visualize.
Related MCP server: Axon
Python 3.10+ is required. Choose one of these installation paths.
This is the simplest option for using Astra. It installs the astra and astra-mcp commands without placing a checkout in your current folder:
python -m pip install "git+https://github.com/nimelkot/astra.git"To upgrade only Astra without reinstalling its already-satisfied dependencies:
python -m pip install --upgrade --no-deps "git+https://github.com/nimelkot/astra.git"--no-deps is the targeted update option: it updates the Astra package and its astra/astra-mcp entry points while skipping dependency resolution and downloads. If the command completes but the installed Astra version or entry points do not update, force-reinstall only Astra while still skipping dependency downloads:
python -m pip install --force-reinstall --no-deps "git+https://github.com/nimelkot/astra.git"Use the regular upgrade command if Astra's dependency requirements have changed or this is a new environment:
python -m pip install --upgrade "git+https://github.com/nimelkot/astra.git"The force-reinstall fallback reinstalls Astra itself but does not reinstall its dependencies because --no-deps is still present. Use it only when the targeted upgrade does not replace the installed package correctly.
For an isolated command-line installation, use pipx:
pipx install "git+https://github.com/nimelkot/astra.git"Use this option when you want to edit Astra or run its tests. Run the editable install from the cloned repository root, the directory containing pyproject.toml:
git clone https://github.com/nimelkot/astra.git
cd astra
Get-ChildItem pyproject.toml
python -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -e ".[dev]"For a checkout that already has Astra installed in editable mode, the fastest update is to pull the latest source and refresh only when dependencies changed:
git pull
python -m pip install -e . --no-depsThe editable package points directly at the checkout, so Python code changes are available immediately. Run the install command again only when pyproject.toml or dependency versions change.
If Get-ChildItem pyproject.toml cannot find the file, you are not in the Astra repository root yet. The folder you want to analyze can be anywhere; it does not need to be inside the Astra checkout.
Index a project first. Replace the example path with the folder you want Astra to analyze:
astra index C:\Users\YourName\Downloads\my-projectThe command recursively scans nested folders for files without importing or executing them. Valid Python files receive AST-level declarations and call relationships. Common source file types (.js, .jsx, .ts, .tsx, .go, .java, .cs, .c, .cc, .cpp, .h, .hpp, .rs, .php, .swift, .kt, .kts, .rb, .dart, .scala, .pl, .r, .m, .lua, .vb, .vbs, .bas, .ps1, .sh, .bash, .zsh, .bat, .cmd, .proto, .graphql, .gql) receive structural declaration and call extraction into the same graph format. SQL files (.sql) receive table/view/function/procedure/trigger extraction and dependency links from statements such as FROM and JOIN. Markdown (.md, .markdown, .mdx) gets section-level extraction, HTML/XML gets element-level extraction, JSON/JSONC and YAML/TOML/INI-style configs get key-level extraction, and BSON files are handled safely with optional key extraction when a BSON decoder is available. Other readable files remain searchable as file-level chunks. Binary files, unsupported encodings, files larger than 2 MB, and generated or dependency directories such as .git, .venv, node_modules, and .astra_vectors are skipped.
For a complete support matrix, see docs/supported-file-types.md.
my-project/
├── .astra_graph.json # structural modules, declarations, and call relationships
└── .astra_vectors/ # local searchable code chunksRun astra index again after the source code changes. Indexing replaces the previous graph and chunk index for that target directory.
Astra uses a lightweight hash cache (.astra_index_cache.json) so repeated indexing only reparses files whose contents changed. Unchanged files reuse cached structural chunks and references.
Search by a concept, behavior, symbol name, or docstring text:
astra search "authentication token validation" --path C:\Users\YourName\Downloads\my-project --limit 8The result table shows the match score, declaration kind, file path, symbol, and source lines. Search results are empty when no indexed chunk shares terms with the query.
Find functions that call a target function:
astra query callers calculate_total --path C:\Users\YourName\Downloads\my-projectThe callers query uses the saved AST graph and reports matching caller nodes as JSON. The current CLI structural query type is callers.
Find the shortest relationship path between two symbols:
astra path "FastAPI" "ModelField" --path C:\Users\YourName\Downloads\my-projectExample output:
FastAPI
fastapi/applications.py:65
↳ DefaultPlaceholder
fastapi/dependencies/models.py:21
↳ get_request_handler()
fastapi/routing.py:310
↳ ModelField
pydantic/fields.py:740
Shortest path (3 hops):
FastAPI --uses--> DefaultPlaceholder <--references-- get_request_handler() --references--> ModelFieldExtract a token-optimized, dependency-complete local sub-graph around a concept or symbol:
astra dipper "checkout flow" --path C:\Users\YourName\Downloads\my-project --limit 6 --parent-depth 1 --child-depth 1The command returns JSON with seeds, nodes, edges, and trimmed source snippets for direct LLM prompting.
Run graph-health checks to flag architectural drift risks:
astra tether --path C:\Users\YourName\Downloads\my-project --cycle-limit 25 --fanout-threshold 12The report includes cycles, orphan declarations, high fan-out symbols, anomaly summaries, and a pass/warn status.
Rank functions and classes by graph centrality, AST complexity, and architectural instability:
astra fragility --path C:\Users\YourName\Downloads\my-project --limit 10 --threshold 75The matching MCP tool is astra_get_fragility_hotspots. See docs/fragility-hotspots.md for the scoring formula and LLM/CI workflows.
Rank declarations that act as high-dependency anchors in the knowledge graph:
astra star-nodes --path C:\Users\YourName\Downloads\my-project --limit 20 --threshold 60The matching MCP tool is astra_star_nodes. Star status combines normalized incoming dependencies and PageRank. In astra visualize, star nodes use a star shape and can be isolated with the Star nodes only filter.
Inspect the upstream blast radius of a declaration:
astra impact calculate_total --path C:\Users\YourName\Downloads\my-projectPreview a graph-ordered identifier rename without changing files:
astra refactor-plan calculate_total sum_total --path C:\Users\YourName\Downloads\my-projectThe MCP equivalents are astra_impact and astra_refactor_plan. astra tether continues to report orphan declarations and circular dependencies, while astra visualize provides the structural anomaly view. See docs/fragility-hotspots.md for the full CLI/MCP workflow.
Map declarations to tests, select tests for changed files, generate a scaffold, or run the selected tests:
astra test-map --path C:\Users\YourName\Downloads\my-project
astra affected-tests app.py --path C:\Users\YourName\Downloads\my-project
astra test-scaffold calculate_total --path C:\Users\YourName\Downloads\my-project
astra run-impacted app.py --path C:\Users\YourName\Downloads\my-projectThe MCP equivalents are astra_test_map, astra_affected_tests, astra_gen_test_scaffold, and astra_run_impacted. These tools automatically refresh the incremental index. The scaffold is read-only, and test execution is limited to graph-selected test files with a configurable timeout.
Recommended policy for pull-request automation:
Fail when new structural cycles are introduced.
Warn when orphan-node count or high-fanout count increases beyond your baseline.
Pass when cycles do not increase and coupling metrics stay within threshold.
A practical CI sequence:
Index the repository snapshot for the PR branch.
Run astra tether and store the JSON output.
Compare summary.cycles, summary.orphans, and summary.high_fanout against your main baseline.
Block merge only for hard-fail conditions (for example, cycle growth).
Post warn-level findings as automated PR comments.
Example command:
astra index C:\Users\YourName\Downloads\my-project
astra tether --path C:\Users\YourName\Downloads\my-project --cycle-limit 25 --fanout-threshold 12The default index is deterministic and works offline using local lexical matching. To enable Sentence Transformers and Chroma vector retrieval, set this before indexing and searching:
$env:ASTRA_ENABLE_EMBEDDINGS = "1"
astra index C:\Users\YourName\Downloads\my-project
astra search "rate limiting and retries" --path C:\Users\YourName\Downloads\my-projectThe first embedding-enabled run may download the all-MiniLM-L6-v2 model. If model access or the vector store is unavailable, Astra falls back to the local search implementation.
After indexing, generate a local HTML report for the target folder:
astra visualize C:\Users\YourName\Downloads\my-projectThis writes .astra_visualization.html into the target folder. Open that file in a browser to inspect two views:
Structural graph: interactive modules, classes, functions, methods, and definition/call edges from .astra_graph.json.
Vector chunks: searchable file and symbol cards from .astra_vectors/chunks.json, with expandable source previews.
Command center: server-computed architecture readiness from astra_health_gate and testing readiness from astra_validate_change in plan mode.
You can choose a different output path:
astra visualize C:\Users\YourName\Downloads\my-project --output C:\Users\YourName\Desktop\astra-report.htmlThe report uses the Vis Network browser library from its CDN for the structural canvas. The vector view and generated data remain local; an internet connection is only needed to load the interactive graph library when opening the report.
The structural graph view renders connected modules, declarations, and relationships across the indexed project:
The vector chunks view provides searchable cards with file paths, symbols, line ranges, and expandable source previews:
Astra also exposes its engine as an official MCP server over stdio. Configure your MCP host to run astra-mcp; the server must be installed in the environment used by that host.
The native tools are:
Tool | Purpose |
| Index a local repository. |
| Search indexed code chunks. |
| Find callers through the structural graph. |
| Find the shortest structural path between two symbols. |
| Scoop a localized dependency-complete sub-graph for token-efficient LLM context. |
| Run structural health checks and return architecture anomaly findings. |
| Rank fragile declarations using graph centrality, AST complexity, and instability. |
| Rank high-importance declarations using incoming dependencies and PageRank. |
| Trace incoming calls and dependencies to report a declaration's blast radius. |
| Preview a graph-ordered, read-only structural identifier rename. |
| Map source declarations to tests that reach them and identify untested nodes. |
| Select the minimal test files affected by changed paths. |
| Generate a read-only pytest scaffold with dependency hints. |
| Run graph-selected tests with a bounded local pytest process. |
| Orchestrate impact, risk, test selection, scaffolding, and validation. |
| Return one architecture-readiness decision for CI and pull requests. |
| Combine semantic matches with graph expansion. |
| Generate a local HTML graph report and return its file path and URL. |
See docs/tool-cookbook.md for example CLI and MCP calls, representative output, use cases, and recommended agent workflows for every tool.
See docs/tools/ for a focused reference page for each CLI/MCP tool, including parameters, output fields, interpretation guidance, and recommended agent sequencing.
See docs/tool-capability-matrix.md for a ranked view of each tool's capability coverage.
The repository includes .vscode/mcp.json for VS Code MCP clients. For other hosts, register the server in the host's configuration:
[mcp_servers.astra]
command = "astra-mcp"
args = []If the host cannot find commands from your shell, use the absolute executable path: .venv\Scripts\astra-mcp.exe on Windows or .venv/bin/astra-mcp on macOS/Linux. The server communicates over stdio, so do not redirect its stdout.
The server also sends automatic MCP initialization instructions with the same baseline workflow, so compatible clients can receive Astra guidance without a slash command. MCP clients that expose prompts can additionally select astra_codebase_workflow with a local path and natural-language task for a task-specific sequence. Astra also publishes a companion <tool>_prompt for every MCP tool, so each tool has a discoverable slash-command workflow. Prompts guide the agent; they do not execute tools themselves.
All analysis and report tools automatically run the incremental index preflight before reading graph or vector artifacts. The hash cache makes unchanged files inexpensive, so an agent can call tools directly after source changes without constructing its own HTML or search index.
For a codebase knowledge-graph visualization, use this sequence:
1. astra_index_repo(path)
2. astra_visualize(path)For investigation before an edit, use astra_hybrid_context or astra_dipper, then astra_impact and astra_get_fragility_hotspots. For a rename, call astra_refactor_plan first, review its read-only changes and order, apply the approved edit through the host's editing capability, then call astra_index_repo and astra_visualize again. Agents should use Astra's returned paths, URLs, nodes, snippets, and JSON reports rather than recreating equivalent artifacts.
For a continuously changing workspace, use astra watch or the MCP watcher lifecycle tools documented in docs/tool-cookbook.md. The watcher is optional; on-demand incremental indexing remains the fallback for short-lived commands and MCP sessions.
Use the server over stdio (astra-mcp) and call tools like astra_dipper and astra_tether from Claude. A complete setup guide is available in docs/claude-desktop.md.
Register Astra with Claude Code from your terminal:
claude mcp add --transport stdio astra -- astra-mcpVerify the server with claude mcp list, then start Claude Code and ask it to use Astra's MCP tools. If astra-mcp is not on your PATH, replace it with the absolute path to .venv\Scripts\astra-mcp.exe on Windows or .venv/bin/astra-mcp on macOS/Linux.
Gemini can consume Astra through any MCP-compatible bridge or local tool host that supports stdio MCP servers. Register astra-mcp, then use astra_dipper to scoop focused context and astra_tether for PR health checks.
Register Astra with Gemini CLI:
gemini mcp add astra astra-mcpVerify the server with gemini mcp list, then start Gemini CLI and ask it to index or search your project with Astra. If astra-mcp is not on your PATH, use the absolute executable path as the command instead.
Codex CLI can run Astra directly from terminal commands:
astra index C:\Users\YourName\Downloads\my-project
astra dipper "payment retry flow" --path C:\Users\YourName\Downloads\my-project
astra tether --path C:\Users\YourName\Downloads\my-projectFor MCP-based Codex workflows, point your MCP client config to astra-mcp and invoke astra_path, astra_dipper, and astra_tether as needed.
pytest
ruff check .Astra never imports or executes files it indexes. Parsing failures are skipped and reported only through the resulting counts, which keeps indexing useful for partially broken working trees.
Find exact callers of a function or method using the structural graph.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No | ||
| target | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the structural-graph mechanism and implies a read-only lookup, but it does not mention prerequisites such as an indexed repository, whether callers are direct or indirect, limits on traversal, or error behavior. This is too little transparency for an unannotated 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?
A single sentence with no filler. 'Exact' and 'structural graph' are meaningful qualifiers, and the core purpose is front-loaded. Every word earns its 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?
Even though an output schema exists, this unannotated tool has three undocumented parameters and no usage guidance. The description does not explain how to construct path/target values, whether the repo must be indexed first, or how result limits behave. An agent would need to guess important invocation details.
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 must compensate. It only hints that 'target' refers to a function or method; it does not explain what 'path' means, how 'limit' applies, or the expected format of 'target'. The description fails to close the parameter documentation gap.
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 uses a specific verb ('Find') and names the resource ('exact callers of a function or method') plus the mechanism ('structural graph'). The qualifiers 'exact' and 'structural' help differentiate it from semantic-search siblings, so an agent can tell what the tool does.
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 phrase 'exact callers' implies a precise, structural query rather than a semantic one, giving some context for when to use it. However, the description never explicitly names alternatives like astra_semantic_search or states when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combine semantic matches with structural expansion.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No | ||
| query | Yes | ||
| expansion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It does not disclose whether the operation reads or writes, whether it is safe to call repeatedly, or any side effects. The phrase 'Combine semantic matches with structural expansion' is too abstract to convey behavioral implications.
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 under-specified fragment rather than a properly sized explanation. It is not well-structured and does not front-load any practical information. While brief, the brevity sacrifices clarity, making it inadequate for an agent selecting the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a two-line description, the tool is critically incomplete. The agent lacks information on what the tool returns, how to construct the path/query, what limit and expansion control, and any usage constraints. This is insufficient for correct invocation.
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 schema describes four parameters (path, query, limit, expansion) with 0% coverage from the description. The description does not explain any parameter's meaning, acceptable values, or how they interact, forcing the agent to guess from names alone. This is a severe gap.
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 gives a general sense of the tool's role ('Combine semantic matches with structural expansion') but does not state a concrete verb+resource outcome or differentiate from siblings like astra_semantic_search and astra_get_callers. It implies a hybrid behavior but is ambiguous about what it actually produces.
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?
No guidance on when to use this tool versus relying on astra_semantic_search alone or astra_get_callers. No exclusions, prerequisites, or context that would help an agent decide between siblings. The description merely states the concept without any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Index a local Python code directory into Astra's graph and vector store.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without disclosing whether the operation is destructive, requires permissions, is additive or overwriting, or what the return value or side effects are. This is a significant gap for a mutating 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?
The description is a single, direct sentence with zero filler. It is appropriately concise and the primary action is stated immediately.
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 an indexing operation with no annotations, no output schema, and an undocumented parameter, the description is critically incomplete. It does not explain prerequisites, the effect on an existing index, or the result of the operation. An agent cannot predict what happens on success or failure.
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 schema provides no description for the sole parameter 'path' (0% coverage), and the tool description does not reference it at all. There is no indication of expected format (absolute vs relative, file vs directory), whether it must exist, or what constraints apply. The agent has no way to correctly populate the parameter.
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 states a specific verb ('Index') and a specific resource ('local Python code directory'), and it is clearly distinct from the sibling tools which are query/visualization operations. The purpose is unambiguous and immediately understood.
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?
No guidance is provided on when to use this tool versus the alternatives. There is no mention that indexing is a prerequisite for search tools, nor any exclusions or conditions that would help an agent decide to call this instead of astra_semantic_search or astra_visualize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search indexed code chunks by conceptual intent.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does convey that this is a read-only semantic lookup over an already-indexed corpus, but it does not disclose ranking behavior, behavior for unindexed paths, or any rate/access constraints.
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 front-loaded sentence with no filler and a clear action-resource structure. It is concise, but the brevity comes at the cost of missing parameter and usage context, so it is not a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape is partially covered, but the description omits essential operational context: what path means, whether the repository must already be indexed, and how this tool relates to astra_index_repo. For a tool with three parameters and no annotations, this is a meaningful gap.
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%, and the description only partially characterizes the query parameter as a 'conceptual intent.' It does not explain what 'path' refers to or how 'limit' affects results, leaving most parameter semantics to the agent to infer.
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 uses a specific verb ('Search'), a resource ('indexed code chunks'), and a method ('by conceptual intent'), making the tool's semantic retrieval purpose clear. It does not explicitly contrast with sibling tools like astra_hybrid_context or astra_get_callers, so it stops short of a top score.
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?
No guidance is given about when to use this tool versus alternatives such as astra_hybrid_context or astra_get_callers. The phrase 'by conceptual intent' hints at semantic queries, but there is no explicit when-to-use, when-not-to-use, or prerequisite such as running astra_index_repo first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a local HTML visualization and return its path and file URL.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| output | No |
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 reveal the key side effect: generating a local HTML file and returning its path/URL. However, it omits whether the file overwrites an existing output, whether it is temporary or persistent, and any resource or environment constraints.
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 is front-loaded with the action and clearly states the return value. Every word contributes to understanding, with no filler or repetition.
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?
There is no output schema, so mentioning the returned path and file URL is useful. However, the required 'path' parameter is unexplained, the optional 'output' parameter is undefined, and there is no context about what should be visualized. A simple tool with two parameters still needs at least minimal input semantics to be invoked 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 description coverage is 0%, and the description does not explain the meaning of the required 'path' parameter or the optional 'output' parameter. The phrase 'return its path and file URL' refers to the result, not the input parameters, leaving the agent without enough information to construct a valid invocation.
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 states a specific action and result: 'Generate a local HTML visualization and return its path and file URL.' It is clear about what the tool does. However, it does not differentiate from sibling tools by naming them or contrasting the visualization use case with indexing/searching.
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?
No guidance is provided about when to use this tool versus alternatives such as astra_index_repo or astra_semantic_search. There is no explicit condition, prerequisite, or exclusions. The intended context is only vaguely implied by the tool name.
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.
v0.1.0astra_get_callersastra_hybrid_contextastra_index_repoastra_semantic_searchastra_visualizeScored across 5 tools
Each tool has a distinct purpose: indexing a repo, semantic search, exact callers, hybrid context, and visualization. No two tools overlap in functionality; agents can easily select the right one.
All tools follow a consistent 'astra_' prefix with verb_noun naming: index_repo, semantic_search, get_callers, hybrid_context, visualize. The pattern is uniform and predictable.
Five tools is an ideal scope for a code indexing and querying server. Each tool serves a core workflow without unnecessary bloat or missing essential operations.
The set covers the main lifecycle: indexing, searching, structural queries, combined retrieval, and visualization. Minor gaps exist (e.g., no delete index or update) but they are not critical for the primary use case.
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
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.
