Skip to main content
Glama
deenesjakoruzh
nimelkot

astra-mcp

by nimelkot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Astra es un servicio de inteligencia de código local para agentes de IA. Analiza los archivos del repositorio en un grafo estructural NetworkX y un índice local de fragmentos de código buscable, con enriquecimiento a nivel de AST para archivos Python válidos. El mismo motor está disponible a través de la CLI astra y el SDK oficial de MCP para Python.

Arquitectura

La marca de la constelación representa las relaciones que Astra descubre en una base de código. Su pipeline tiene cuatro etapas: descubrir archivos sin ejecutarlos, construir el grafo estructural, indexar fragmentos de código y recuperar coincidencias semánticas con expansión de grafo.

Componente

Rol

Salida

Analizador de AST y texto

Lee declaraciones de Python, docstrings, símbolos y llamadas; indexa otros archivos de proyecto legibles como fragmentos a nivel de archivo.

Fragmentos de código y referencias

Grafo estructural

Construye relaciones dirigidas de NetworkX entre módulos, declaraciones y llamadores.

.astra_graph.json

Índice vectorial

Almacena fragmentos buscables localmente, con aceleración opcional de Sentence Transformers y Chroma.

.astra_vectors/

Interfaces duales

Hace que el mismo motor esté disponible para usuarios de terminal y hosts MCP.

astra y astra-mcp

La superficie MCP expone cuatro herramientas: astra_index_repo, astra_semantic_search, astra_get_callers y astra_hybrid_context.

Related MCP server: codebase-mcp

Instalación

Se requiere Python 3.10+. Elige una de estas rutas de instalación.

Instalar directamente desde GitHub

Esta es la opción más sencilla para usar Astra. Instala los comandos astra y astra-mcp sin colocar un checkout en tu carpeta actual:

python -m pip install "git+https://github.com/nimelkot/astra.git"

Para una instalación aislada de línea de comandos, usa pipx:

pipx install "git+https://github.com/nimelkot/astra.git"

Clonar para desarrollo

Usa esta opción cuando quieras editar Astra o ejecutar sus pruebas. Ejecuta la instalación editable desde la raíz del repositorio clonado, el directorio que contiene 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]"

Si Get-ChildItem pyproject.toml no puede encontrar el archivo, aún no estás en la raíz del repositorio de Astra. La carpeta que quieres analizar puede estar en cualquier lugar; no necesita estar dentro del checkout de Astra.

Inicio rápido

Indexa un proyecto primero. Reemplaza la ruta de ejemplo con la carpeta que quieres que Astra analice:

astra index C:\Users\YourName\Downloads\my-project

El comando escanea recursivamente las carpetas anidadas en busca de archivos sin importarlos ni ejecutarlos. Los archivos Python válidos reciben declaraciones a nivel de AST y relaciones de llamadas; otros archivos de código fuente, configuración, marcado y documentación legibles reciben fragmentos a nivel de archivo buscables. Se omiten los archivos binarios, las codificaciones no compatibles, los archivos de más de 2 MB y los directorios generados o de dependencias como .git, .venv, node_modules y .astra_vectors.

Para una matriz de compatibilidad completa, consulta docs/supported-file-types.md.

my-project/
├── .astra_graph.json   # structural modules, declarations, and call relationships
└── .astra_vectors/     # local searchable code chunks

Ejecuta astra index de nuevo después de que cambie el código fuente. La indexación reemplaza el grafo y el índice de fragmentos anteriores para ese directorio de destino.

CLI

Búsqueda semántica

Busca por concepto, comportamiento, nombre de símbolo o texto de docstring:

astra search "authentication token validation" --path C:\Users\YourName\Downloads\my-project --limit 8

La tabla de resultados muestra la puntuación de coincidencia, el tipo de declaración, la ruta del archivo, el símbolo y las líneas de origen. Los resultados de búsqueda están vacíos cuando ningún fragmento indexado comparte términos con la consulta.

Llamadores estructurales

Encuentra funciones que llaman a una función objetivo:

astra query callers calculate_total --path C:\Users\YourName\Downloads\my-project

La consulta callers usa el grafo AST guardado y reporta los nodos de llamadores coincidentes como JSON. El tipo de consulta estructural actual de la CLI es callers.

Comportamiento de búsqueda

El índice predeterminado es determinista y funciona sin conexión mediante coincidencia léxica local. Para habilitar la recuperación vectorial de Sentence Transformers y Chroma, establece esto antes de indexar y buscar:

$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-project

La primera ejecución con embeddings habilitados puede descargar el modelo all-MiniLM-L6-v2. Si el acceso al modelo o el almacén de vectores no está disponible, Astra recurre a la implementación de búsqueda local.

Visualizar un índice

Después de indexar, genera un informe HTML local para la carpeta de destino:

astra visualize C:\Users\YourName\Downloads\my-project

Esto escribe .astra_visualization.html en la carpeta de destino. Abre ese archivo en un navegador para inspeccionar dos vistas:

  • Grafo estructural: módulos, clases, funciones, métodos y aristas de definición/llamada interactivos desde .astra_graph.json.

  • Fragmentos vectoriales: tarjetas de archivos y símbolos buscables desde .astra_vectors/chunks.json, con vistas previas de código expandibles.

Puedes elegir una ruta de salida diferente:

astra visualize C:\Users\YourName\Downloads\my-project --output C:\Users\YourName\Desktop\astra-report.html

El informe usa la librería de navegador Vis Network desde su CDN para el lienzo estructural. La vista vectorial y los datos generados permanecen locales; solo se necesita conexión a internet para cargar la librería de grafo interactivo al abrir el informe.

Ejemplos de visualización

La vista de grafo estructural renderiza módulos, declaraciones y relaciones conectadas en el proyecto indexado:

La vista de fragmentos vectoriales proporciona tarjetas buscables con rutas de archivo, símbolos, rangos de líneas y vistas previas de código expandibles:

MCP

Astra también expone su motor como un servidor MCP oficial sobre stdio. Configura tu host MCP para ejecutar astra-mcp; el servidor debe estar instalado en el entorno utilizado por ese host.

Las cuatro herramientas nativas son:

Herramienta

Propósito

astra_index_repo(path)

Indexa un repositorio local.

astra_semantic_search(path, query, limit)

Busca fragmentos de código indexados.

astra_get_callers(path, target, limit)

Encuentra llamadores a través del grafo estructural.

astra_hybrid_context(path, query, limit, expansion)

Combina coincidencias semánticas con expansión de grafo.

astra_visualize(path, output)

Genera un informe HTML de grafo local y devuelve su ruta de archivo y URL.

El repositorio incluye .vscode/mcp.json para clientes MCP de VS Code. Para otros hosts, registra el servidor en la configuración del host:

[mcp_servers.astra]
command = "astra-mcp"
args = []

Si el host no puede encontrar los comandos desde tu shell, usa la ruta absoluta del ejecutable: .venv\Scripts\astra-mcp.exe en Windows o .venv/bin/astra-mcp en macOS/Linux. El servidor se comunica a través de stdio, así que no redirijas su stdout.

Desarrollo

pytest
ruff check .

Astra nunca importa ni ejecuta los archivos que indexa. Los fallos de análisis se omiten y se reportan solo a través de los recuentos resultantes, lo que mantiene la indexación útil para árboles de trabajo parcialmente rotos.

Available Tools

5 tools
astra_get_callersB

Find exact callers of a function or method using the structural graph.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
limitNo
targetYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. 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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. 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.

Purpose5/5

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.

Usage Guidelines3/5

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.

astra_hybrid_contextC

Combine semantic matches with structural expansion.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
limitNo
queryYes
expansionNo

TDQS

C2/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the 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.

Conciseness2/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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.

astra_index_repoC

Index a local Python code directory into Astra's graph and vector store.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

astra_visualizeC

Generate a local HTML visualization and return its path and file URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
outputNo

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It does 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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedastra_get_callers
    • First observedastra_hybrid_context
    • First observedastra_index_repo
    • First observedastra_semantic_search
    • First observedastra_visualize
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.2/5.0

Scored across 5 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • codebase-mcp

    theunreal
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to semantically search and navigate code repositories using natural language, with support for multiple repos, incremental indexing, and no local install needed.
    -

  • codebase-rag

    Ar-maan05
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables LLM agents to efficiently understand and navigate a codebase by providing semantic search over symbols and a reference graph, replacing expensive grep/glob calls with structured tools like definition lookup, caller/callee queries, and change-impact analysis.
    18 PyPI
    3
    MIT

  • mcp-intelligence-context

    LeoChimal09
    F
    license
    A
    quality
    C
    maintenance
    Provides codebase indexing and retrieval tools that give AI agents token-efficient, query-relevant context packages (symbols, imports, and dependencies) instead of scanning entire repositories.
    6
    -