Skip to main content
Glama
deenesjakoruzh
nimelkot

astra-mcp

by nimelkot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Astra는 AI 에이전트를 위한 로컬 코드 인텔리전스 서비스입니다. 저장소 파일을 구조적 NetworkX 그래프와 검색 가능한 로컬 코드 청크 인덱스로 파싱하며, 유효한 Python 파일에는 AST 수준의 강화(enhancement)를 적용합니다. 동일한 엔진은 astra CLI와 공식 MCP Python SDK를 통해 사용할 수 있습니다.

아키텍처

별자리(constellation) 마크는 Astra가 코드베이스 전반에서 발견하는 관계를 나타냅니다. 파이프라인은 네 단계로 구성됩니다: 파일을 실행하지 않고 발견하기, 구조적 그래프 구축하기, 코드 청크 인덱싱하기, 그래프 확장과 함께 의미적 매칭 검색하기.

구성 요소

역할

출력

AST 및 텍스트 파서

Python 선언, docstring, 심볼, 호출을 읽고; 다른 읽기 가능한 프로젝트 파일을 파일 수준 청크로 인덱싱합니다.

코드 청크 및 참조

구조적 그래프

모듈, 선언, 호출자 간의 방향성 있는 NetworkX 관계를 구축합니다.

.astra_graph.json

벡터 인덱스

선택적으로 Sentence Transformers 및 Chroma 가속을 사용하여 검색 가능한 청크를 로컬에 저장합니다.

.astra_vectors/

이중 인터페이스

동일한 엔진을 터미널 사용자와 MCP 호스트 모두에게 제공합니다.

astra 및 astra-mcp

MCP 표면은 네 가지 도구를 노출합니다: astra_index_repo, astra_semantic_search, astra_get_callers, astra_hybrid_context.

Related MCP server: codebase-mcp

설치

Python 3.10 이상이 필요합니다. 다음 설치 경로 중 하나를 선택하세요.

GitHub에서 직접 설치

이 방법은 Astra를 사용하기 위한 가장 간단한 옵션입니다. 현재 폴더에 체크아웃을 두지 않고 astra 및 astra-mcp 명령을 설치합니다:

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

격리된 명령줄 설치를 원하면 pipx를 사용하세요:

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

개발용 클론

Astra를 편집하거나 테스트를 실행하려는 경우 이 옵션을 사용하세요. 클론한 저장소 루트, 즉 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]"

Get-ChildItem pyproject.toml이 파일을 찾지 못하면 아직 Astra 저장소 루트에 있지 않은 것입니다. 분석하려는 폴더는 어디에 있어도 되며, Astra 체크아웃 내부에 있을 필요는 없습니다.

빠른 시작

먼저 프로젝트를 인덱싱하세요. 예시 경로를 Astra가 분석하려는 폴더로 바꾸세요:

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

이 명령은 파일을 가져오거나 실행하지 않고 중첩된 폴더를 재귀적으로 스캔합니다. 유효한 Python 파일은 AST 수준의 선언과 호출 관계를 받고, 다른 읽기 가능한 소스, 구성, 마크업, 문서 파일은 검색 가능한 파일 수준 청크를 받습니다. 바이너리 파일, 지원되지 않는 인코딩, 2MB보다 큰 파일, 그리고 .git, .venv, node_modules, .astra_vectors와 같은 생성 또는 의존성 디렉터리는 건너뜁니다.

전체 지원 매트릭스는 docs/supported-file-types.md를 참조하세요.

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

소스 코드가 변경된 후 astra index를 다시 실행하세요. 인덱싱은 해당 대상 디렉터리의 이전 그래프와 청크 인덱스를 대체합니다.

CLI

의미적 검색

개념, 동작, 심볼 이름 또는 docstring 텍스트로 검색하세요:

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

결과 테이블은 매칭 점수, 선언 종류, 파일 경로, 심볼, 소스 줄을 보여줍니다. 인덱싱된 청크 중 쿼리와 용어를 공유하는 항목이 없으면 검색 결과는 비어 있습니다.

구조적 호출자

대상 함수를 호출하는 함수를 찾으세요:

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

callers 쿼리는 저장된 AST 그래프를 사용하며 일치하는 호출자 노드를 JSON으로 보고합니다. 현재 CLI 구조적 쿼리 유형은 callers입니다.

검색 동작

기본 인덱스는 결정적이며 로컬 어휘 매칭을 사용하여 오프라인으로 작동합니다. Sentence Transformers 및 Chroma 벡터 검색을 활성화하려면 인덱싱 및 검색 전에 다음을 설정하세요:

$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

임베딩 활성화 첫 실행 시 all-MiniLM-L6-v2 모델을 다운로드할 수 있습니다. 모델 접근 또는 벡터 저장소를 사용할 수 없으면 Astra는 로컬 검색 구현으로 대체합니다.

인덱스 시각화

인덱싱 후 대상 폴더에 대한 로컬 HTML 보고서를 생성하세요:

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

이 명령은 대상 폴더에 .astra_visualization.html을 작성합니다. 브라우저에서 해당 파일을 열어 두 가지 뷰를 확인하세요:

  • 구조적 그래프: .astra_graph.json의 대화형 모듈, 클래스, 함수, 메서드, 정의/호출 엣지.

  • 벡터 청크: .astra_vectors/chunks.json의 검색 가능한 파일 및 심볼 카드, 확장 가능한 소스 미리보기 포함.

다른 출력 경로를 선택할 수 있습니다:

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

보고서는 구조적 캔버스에 Vis Network 브라우저 라이브러리를 CDN에서 사용합니다. 벡터 뷰와 생성된 데이터는 로컬에 유지됩니다. 인터넷 연결은 보고서를 열 때 대화형 그래프 라이브러리를 로드하는 데만 필요합니다.

시각화 예시

구조적 그래프 뷰는 인덱싱된 프로젝트 전반의 연결된 모듈, 선언, 관계를 렌더링합니다:

벡터 청크 뷰는 파일 경로, 심볼, 줄 범위, 확장 가능한 소스 미리보기가 포함된 검색 가능한 카드를 제공합니다:

MCP

Astra는 또한 자체 엔진을 stdio를 통한 공식 MCP 서버로 노출합니다. MCP 호스트가 astra-mcp를 실행하도록 구성하세요. 서버는 해당 호스트가 사용하는 환경에 설치되어 있어야 합니다.

네 가지 네이티브 도구는 다음과 같습니다:

도구

용도

astra_index_repo(path)

로컬 저장소를 인덱싱합니다.

astra_semantic_search(path, query, limit)

인덱싱된 코드 청크를 검색합니다.

astra_get_callers(path, target, limit)

구조적 그래프를 통해 호출자를 찾습니다.

astra_hybrid_context(path, query, limit, expansion)

의미적 매칭과 그래프 확장을 결합합니다.

astra_visualize(path, output)

로컬 HTML 그래프 보고서를 생성하고 파일 경로와 URL을 반환합니다.

저장소에는 VS Code MCP 클라이언트용 .vscode/mcp.json이 포함되어 있습니다. 다른 호스트의 경우 호스트 구성에 서버를 등록하세요:

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

호스트가 셸에서 명령을 찾지 못하면 절대 실행 파일 경로를 사용하세요: Windows에서는 .venv\Scripts\astra-mcp.exe, macOS/Linux에서는 .venv/bin/astra-mcp. 서버는 stdio를 통해 통신하므로 stdout을 리디렉션하지 마세요.

개발

pytest
ruff check .

Astra는 인덱싱하는 파일을 절대 가져오거나 실행하지 않습니다. 파싱 실패는 건너뛰고 결과 개수를 통해서만 보고되므로, 부분적으로 손상된 작업 트리에서도 인덱싱이 유용하게 유지됩니다.

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
    -