Skip to main content
Glama
LuisCarlosLopes

codesteer-atlas

by LuisCarlosLopes
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

CodeSteer Atlas

Servidor MCP local para busca semântica em código. Usa Tree-sitter (AST), embeddings locais (fastembed/ONNX) e LanceDB. Tudo roda 100% offline — o código-fonte nunca sai da sua máquina.

Documentação

Recurso

Descrição

📖 Documentação visual

Conceitos MCP, busca híbrida e indexação

📘 Guia didático — Indexação, Grafo e MCP

Pipeline, diagramas, multi-repo e graph.html

Funcionalidades

  • Indexação por AST (Tree-sitter): chunks por classe/função/método, não por blocos arbitrários de linhas.

  • Busca híbrida: similaridade vetorial + BM25, fundidas via RRF.

  • Indexação incremental: só arquivos novos/alterados (hash sha256).

  • Embeddings locais: all-MiniLM-L6-v2 (384 dims) via fastembed, com lazy loading.

  • Grafo de conhecimento: .code-index/graph.json + visualizador graph.html (abre via file://).

  • Rationale em código: NOTE/WHY, cites DEC/ADR/RFC e wikilinks nos resultados de busca.

  • Multi-linguagem: Python, JS/TS, Go, Java, C#, Dart, Pascal, VB6, Razor, XML, Markdown e mais.

Related MCP server: embecode

Começar (3 passos)

Pré-requisitos: Python 3.11–3.13 e uv (fornece o uvx).

Você não precisa clonar este repositório para usar o Atlas. O índice fica em .code-index/ na raiz do seu projeto (adicione essa pasta ao .gitignore).

1. Conectar o MCP no seu projeto

Importante — não instale o plugin em escopo global (user).

Plugins/MCP globais costumam iniciar o servidor com CWD = $HOME, sem a raiz do projeto aberto. Nesse caso o Atlas não consegue inferir de forma confiável a pasta .code-index do workspace (e pode criar ou achar um índice no lugar errado).

Use sempre uma destas opções:

  1. Plugin no projeto atual (escopo project ou local), ou

  2. Configuração manual via mcp.json / .mcp.json na raiz do projeto.

Opção A — Plugin no projeto atual (Claude Code)

/plugin marketplace add LuisCarlosLopes/codesteer-atlas
# ou pasta local: /plugin marketplace add /caminho/para/codesteer-atlas

/plugin install codesteer-atlas

Quando o Claude Code pedir o escopo, escolha Project (compartilhado no repo) ou Local (só neste workspace). Não escolha User.

Pela CLI:

claude plugin install codesteer-atlas --scope project
# ou: --scope local

Opção B — mcp.json manual (recomendado para Cursor, VS Code, Kiro, OpenCode…)

Copie o manifest para a raiz do seu projeto (não para a config global do editor) e reinicie o cliente:

Cliente

Copiar de

Para

Cursor

examples/clients/cursor/mcp.json

.cursor/mcp.json

GitHub Copilot (VS Code)

examples/clients/vscode/mcp.json

.vscode/mcp.json

Kiro

examples/clients/kiro/settings/mcp.json

.kiro/settings/mcp.json

OpenCode

examples/clients/opencode/opencode.json

opencode.json

Claude Code

.mcp.json

.mcp.json na raiz do projeto

Exemplo mínimo (Claude Code / vários clientes com chave mcpServers):

{
  "mcpServers": {
    "codesteer-atlas": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/LuisCarlosLopes/codesteer-atlas.git",
        "atlas-serve"
      ]
    }
  }
}

Detalhes por cliente e modo instalado (uv tool install): examples/clients/ e CONTRIBUTING.md.

Outros canais (também por projeto)

  • Kiro Power: Add Custom Power → Import from GitHub → https://github.com/LuisCarlosLopes/codesteer-atlas.git, e associe ao workspace atual.

  • Copilot CLI plugin: prefira instalar no contexto do repositório em que você vai trabalhar; se o índice não for encontrado, use a Opção B (.vscode/mcp.json ou equivalente).

copilot plugin install LuisCarlosLopes/codesteer-atlas

2. Indexar o projeto

Na raiz do seu projeto (não do repositório do Atlas, a menos que seja esse o alvo):

cd /caminho/para/seu-projeto

# Uma vez: instala atlas-index / atlas-serve no PATH
uv tool install git+https://github.com/LuisCarlosLopes/codesteer-atlas.git

atlas-index --workspace .

Sem instalar no PATH (baixa o pacote a cada execução):

uvx --from git+https://github.com/LuisCarlosLopes/codesteer-atlas.git atlas-index --workspace .

Ao terminar: mensagem Indexação Concluída com Sucesso! e pasta .code-index/ com manifest.json, lancedb/, graph.json e graph.html.

Atualizar o Atlas depois: uv tool upgrade codesteer-atlas.

3. Usar

Com o MCP conectado e o índice criado, o agente passa a ter as tools atlas_*. Nas próximas vezes:

atlas-index --workspace .            # incremental (padrão)
atlas-index --workspace . --full     # rebuild completo
atlas-index --workspace . --paths src --paths docs

Ou peça ao agente para usar a tool atlas_index.

Reindex automático: ao iniciar o atlas-serve (abrir/reiniciar o editor), se .code-index/ já existir, roda uma reindexação incremental em background. A primeira indexação (passo 2) continua manual. Log: .code-index/background_reindex.log.

Uso

Tool

Descrição

atlas_search

Busca híbrida. Por padrão retorna só metadados; use include_content=true ou Read nas linhas. Filtros: repo, language, path_prefix.

atlas_brief

Briefing do projeto (identidade, camadas, entrypoints, hubs). Chame primeiro em projeto desconhecido. level=0 ou 1.

atlas_graph

Grafo: hubs, path, explain.

atlas_index

Indexa/reindexa; regenera graph.json / graph.html. Suporta dry_run.

atlas_status

Diagnóstico do índice (is_stale, graph_available, index_resolution, …).

Recurso somente leitura: atlas://status.

Após indexar, abra .code-index/graph.html no navegador (file://) para inspecionar o grafo.

Rationale e grafo

Em resultados de código, atlas_search pode incluir rationale_refs (DECISAO-002, ADR-001, [[wikilinks]], # NOTE: / # WHY:).

atlas_graph(mode="hubs", top_n=10)
atlas_graph(mode="path", source="src/app.py", target="dec-002")
atlas_graph(mode="explain", target="AuthService.login")

Upgrade: atlas_graph / graph.html exigem reindex em índices antigos (< 2.1.0).

Instruções para agentes de IA (AGENTS.md / CLAUDE.md)

Copie o bloco abaixo para as instruções do seu projeto:

Cliente / IDE

Arquivo

Cursor, Copilot (VS Code), genérico

AGENTS.md

Claude Code

CLAUDE.md

Kiro

regras do Power / instruções do agente

GitHub Copilot CLI

instruções do plugin ou regras do projeto

# Busca de código com `codesteer-atlas`

Este repositório é indexado pelo MCP `codesteer-atlas`. Para entender, planejar, pesquisar ou explorar código, use Atlas antes de `grep`, `rg`, `find`, glob ou leitura em massa.

## Use assim

- `atlas_brief`: orientar-se num projeto desconhecido — chame primeiro, uma vez
- `atlas_search`: localizar função, classe, método, símbolo ou conceito
- `atlas_graph`: hubs, paths e conexões (código, markdown, rationale)
- `atlas_status`: só se houver suspeita de índice ausente ou desatualizado
- `atlas_index`: reindexar após mudanças grandes ou índice stale

## Fluxo padrão

1. `atlas_search` para descoberta (metadados).
2. Restrinja com `path_prefix` e `language` quando fizer sentido.
3. Leia os hits com `Read`, ou repita com `include_content=true`.

## Quando pode pular o Atlas

- o usuário já informou o caminho exato
- confirmação de string literal exata
- edição, diff, commit, git, CI, testes ou instalação de deps
- MCP indisponível ou índice vazio/desatualizado

## Índice desatualizado

1. `atlas_status`
2. Se necessário, `atlas_index`
3. Fallback local só se o problema persistir

Como funciona

O Atlas divide cada arquivo em CodeChunks no nível de símbolo via Tree-sitter, gera embeddings locais e indexa em LanceDB (vetorial + BM25 / RRF):

src/auth/service.py
  ├── class AuthService          (linhas 10–45)
  ├── AuthService.login          (linhas 20–35)
  └── AuthService.logout         (linhas 37–44)

Detalhes do pipeline: CONTRIBUTING.md.

Excluindo arquivos com .atlasignore

Na raiz do workspace (sintaxe igual à do .gitignore):

*.log
fixtures/
/dist
**/*.generated.py
!important.log

É um filtro adicional — .git, node_modules, .venv, __pycache__ e .code-index continuam sempre ignorados.

Onde fica o .code-index?

Ordem de resolução:

  1. --index-dir (CLI)

  2. ATLAS_INDEX_DIR (env)

  3. Busca ascendente a partir do CWD

  4. Busca a partir da raiz do editor (CLAUDE_PROJECT_DIR, WORKSPACE_FOLDER_PATHS)

  5. Fallback .code-index relativo à raiz conhecida (ou ao CWD)

Com MCP ligado ao projeto (plugin project/local ou mcp.json na raiz), o item 3 ou 4 costuma bastar após atlas-index --workspace ..

Se o servidor nascer com CWD errado (caso típico de instalação global), o Atlas tenta recuperar via MCP roots/list quando o cliente suporta. Mesmo assim, prefira instalação por projeto — é o caminho estável.

Para forçar um caminho explícito no mcp.json do projeto:

{
  "mcpServers": {
    "codesteer-atlas": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/LuisCarlosLopes/codesteer-atlas.git",
        "atlas-serve"
      ],
      "env": {
        "ATLAS_INDEX_DIR": "${workspaceFolder}/.code-index"
      }
    }
  }
}

No Cursor, ${workspaceFolder} é a forma mais segura de amarrar o índice ao projeto aberto. Veja CONTRIBUTING.md — Cursor.

Diagnóstico: atlas_status → index_resolution.

Contribuindo

Clonar o repo, testes, lint e configuração avançada: CONTRIBUTING.md e CLAUDE.md.

Licença

Veja LICENSE.

Available Tools

5 tools
atlas_briefA

Get a pre-computed, token-bounded briefing that orients you in an unfamiliar project.

Call this FIRST, once, when you start working on a project you do not already know. It replaces the usual orientation ritual (listing directories, reading the README, opening several files just to get your bearings) with a single small response.

Returns a ranked summary: identity (repo, language distribution, size), layers (the main directories, what role each plays, and their most important files), entrypoints (how the project is actually started), and hubs (the most connected files — the ones whose change propagates furthest). Every list is ranked and capped, so the response size does NOT grow with the size of the repository.

Do NOT call this to enumerate symbols or files: by design it reports at most a handful of layers and a few files per layer. Use atlas_search (optionally with path_prefix) to find a specific implementation, and atlas_graph to explore connectivity. Do NOT call it more than once per session — the briefing only changes after atlas_index re-runs.

Facts are derived deterministically from the index; nothing is guessed. Entries carry confidence (declared when read from a manifest such as pyproject/package.json, inferred when detected in code) and warnings reports known gaps, e.g. graph_unavailable, no_import_edges, low_symbol_coverage, index_stale.

Staleness is detected by comparing the indexed git HEAD with the current one, so uncommitted edits are not detected (same limitation as atlas_status).

ParametersJSON Schema
NameRequiredDescriptionDefault
levelNoDetail level. `0` is a minimal orientation (identity plus directory roles); `1` (default) adds per-layer top files, entrypoints and hubs.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses deterministic derivation, response size capped independent of repo size, ranked/capped lists, confidence levels with declared vs inferred, known warning types, and staleness detection limitations including the inability to detect uncommitted edits.

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 longer than average but every sentence earns its place. It is front-loaded with a one-sentence summary, followed by explicit usage instructions, output details, and limitations, without redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the absence of annotations, the description covers all necessary context: what it does, when to call it, what it returns, how to interpret results, known edge cases, and relationships to sibling tools. The output schema existence further reduces the need to explain return types, but the description goes beyond that anyway.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description does not add new meaning about the `level` parameter beyond what the schema already says, though it enriches the overall understanding of the response shape (ranked, capped lists) which indirectly informs parameter expectations.

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 opens with a specific verb+resource: 'Get a pre-computed, token-bounded briefing that orients you in an unfamiliar project.' It clearly distinguishes the tool from siblings by explicitly naming atlas_search, atlas_graph, and atlas_index and stating what each is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance ('Call this FIRST, once, when you start working on a project you do not already know'), what not to use it for, and names alternative tools for specific tasks. It also warns against repeated calls and notes when the briefing changes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

atlas_graphA

Query the derived knowledge graph for hubs, paths, or neighborhood explanations.

Call this directly when the question is about connectivity, rationale, or centrality in the indexed workspace. It reads the derived graph.json produced by atlas_index; it does not rebuild the graph itself.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYesOne of `hubs`, `path`, or `explain`.
top_nNoNumber of hubs to return for `hubs` mode. Must be between 1 and 50.
sourceNoRequired for `path`. Accepts exact node id, exact label, or a unique suffix.
targetNoRequired for `path` and `explain`. Accepts exact node id, exact label, or a unique suffix.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses that the tool reads the derived graph.json produced by atlas_index and does not rebuild the graph, indicating a read-only dependency on a precomputed artifact. This is useful context, though it omits details like staleness or side effects (which are minimal for a read-only query).

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 two sentences long, with the main verb and resource front-loaded. The second sentence adds essential context about when to use and the dependency on atlas_index. Every phrase earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of a full output schema and complete parameter descriptions, the description does not need to explain return values or parameter details. It covers the core purpose, usage context, and dependency, which is sufficient for a tool of this complexity. Minor gaps like explicit exclusions or performance notes are not critical because the schema fills in details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema already provides 100% coverage, with descriptions for every parameter including conditional requirements (e.g., 'Required for path'). The description adds no additional parameter-level information, so it sustains the baseline score of 3 but does not elevate it.

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 clearly states the tool queries the derived knowledge graph for hubs, paths, or neighborhood explanations. The verb 'query' and the specific resource ('derived knowledge graph') distinguish it from siblings that operate on raw indices or briefs. It also specifies the graph is derived from atlas_index, providing unique identity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to call this tool when the question concerns connectivity, rationale, or centrality, which gives clear usage context. It also notes it does not rebuild the graph, implying it is for read-only queries. However, it does not explicitly name alternative tools or contrast with them, though the 'call directly' phrase hints at direct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

atlas_indexA

Index (or re-index) source code and documents into the local search index.

Use to build the index the first time, or to refresh it after atlas_status reports is_stale: true or large changes.

IMPORTANT: unless the user already said what to index, call with dry_run=true first, show the candidate folders, and ASK whether to index everything or specific folders. Then call again with the chosen 'paths' (or none for the whole workspace).

Incremental by default: unchanged files (by content hash) are skipped, so re-runs are fast. full=true forces a complete rebuild.

full=true or empty/omitted 'paths' (whole-workspace) run asynchronously in a background subprocess and return immediately — poll atlas_status (reindexing: true while running). A non-empty 'paths' with full=false runs synchronously and returns stats directly.

ParametersJSON Schema
NameRequiredDescriptionDefault
fullNoForce full re-index ignoring cached hashes. Defaults to false.
pathsNoOptional subfolders (relative to 'workspace') to index, e.g. ["src", "docs"]. Omitted = whole workspace. No path traversal outside it.
dry_runNoWhen true, indexes nothing; returns top-level candidate folders with eligible-file counts so you can present them before deciding. Defaults to false.
workspaceNoAbsolute path to index. Defaults to the parent of the resolved index, else the current directory. Must exist and be a directory.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

No annotations provided, but description fully discloses incremental behavior, skip of unchanged files, async/sync modes, and dry_run behavior. No contradictions.

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?

Well-structured, concise with clear sections. Each sentence adds value; no fluff. Front-loaded with purpose, then usage notes, then behavioral details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given four parameters, async behavior, and an output schema, the description covers all necessary context: workflow, behaviors, edge cases (dry_run, full rebuild). Output schema exists, so return values need not be described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema already covers all parameters (100% coverage). Description adds value by explaining how parameters affect execution (e.g., dry_run returns candidates, non-empty paths with full=false is synchronous) and usage patterns.

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 clearly states the tool indexes source code and documents into a local search index, using specific verbs and resources. It distinguishes from the sibling tool 'atlas_search' which presumably searches, not indexes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance on when to use (first time, after staleness) and when not (use dry_run first, ask user). Provides workflow instructions and distinguishes between async and sync execution based on parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

atlas_statusA

Get diagnostic metadata and health status of the local vector index.

Use this only for explicit diagnostics (e.g. the user asks about index health, staleness, or which repos/languages are indexed) or to decide whether atlas_index should be run. It is NOT a precondition for atlas_search/atlas_brief — call those directly; they raise an actionable error themselves if the index is missing. Never indexes anything itself.

Returns: JSON string with index_exists, total_chunks, repos_indexed, languages_indexed, embedding_model, embedding_backend, storage_backend, index_path, index_resolution (how the index directory was resolved: "cli-arg" | "env" | "discovery" | "editor-project-dir" | "roots" | "roots-fallback" | "editor-project-dir-fallback" | "cwd-fallback" — useful to diagnose client misconfiguration when index_exists is unexpectedly false), last_indexed_at, git_head_sha, is_stale (true when the indexed git HEAD differs from the workspace's current HEAD), and reindexing (true when another process currently holds the reindex lock for this index).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool never indexes anything, and it discloses important behavioral details such as the reindex lock ('reindexing' true when another process holds the lock), staleness semantics, and index resolution modes. This gives the agent a strong understanding of side effects and edge cases.

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 front-loaded with a clear one-sentence purpose, followed by usage guidance and a detailed return list. Every sentence serves a purpose: usage restrictions, non-side-effect guarantee, and return field explanations. It is appropriately sized for the tool's diagnostic nature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully compensates for the lack of annotations by documenting the output fields, including edge-case values like index_resolution and is_stale. It is complete for a diagnostic tool with no parameters and no side effects, and it provides enough context for the agent to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

The tool has zero parameters, so the schema already covers everything. The description adds no parameter-specific details, but with no parameters the baseline is 4, and the description's return-value documentation compensates for any lack of parameter context.

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 action ('Get diagnostic metadata and health status of the local vector index') tied to a clear resource (local vector index). It distinguishes itself from sibling tools by explicitly stating it is not a precondition for atlas_search/atlas_brief and never indexes anything.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use (explicit diagnostics or deciding whether atlas_index should run) and when not to use (not a precondition for search/brief; call those directly). It also names an alternative tool (atlas_index) and clarifies that search/brief raise errors themselves if the index is missing.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.4.3
    • Addedatlas_brief
    • Addedatlas_graph
    • Addedatlas_status
  2. 4 tool updatesv1.4.2
    • Changedatlas_index4 fields changed
      • changedInput schema / properties / dry_run / description
        Previous value: -"When true, does NOT index anything. Instead, returns the\ntop-level candidate folders under 'workspace' with a count of\neligible files in each, so the agent can present them to the user\nbefore deciding what to index. Defaults to false."New value: +"When true, indexes nothing; returns top-level candidate folders\nwith eligible-file counts so you can present them before deciding.\nDefaults to false."
      • changedInput schema / properties / full / description
        Previous value: -"When true, forces a full re-index ignoring cached file hashes.\nDefaults to false (incremental)."New value: +"Force full re-index ignoring cached hashes. Defaults to false."
      • changedInput schema / properties / paths / description
        Previous value: -"Optional list of subfolder paths, relative to 'workspace', to index\n(e.g. [\"src\", \"docs\"]). When omitted, the entire workspace is indexed.\nEach path must resolve to a location inside 'workspace' (no path traversal)."New value: +"Optional subfolders (relative to 'workspace') to index, e.g.\n[\"src\", \"docs\"]. Omitted = whole workspace. No path traversal outside it."
      • changedInput schema / properties / workspace / description
        Previous value: -"Absolute path to the root directory to index. Defaults to the\nparent directory of the resolved index, or the current working\ndirectory if no index has been resolved yet. Must exist and be a directory."New value: +"Absolute path to index. Defaults to the parent of the resolved\nindex, else the current directory. Must exist and be a directory."
    • Removedatlas_map
    • Changedatlas_search8 fields changed
      • changedInput schema / properties / include_content / default
        Previous value: -trueNew value: +false
      • changedInput schema / properties / include_content / description
        Previous value: -"When false, omits the 'content' field from results to save tokens,\nreturning only metadata and location (file_path, lines, symbol, type, language, score).\nDefaults to true."New value: +"When true, includes each result's 'content'. Defaults to false\n(metadata/location only) to save tokens."
      • changedInput schema / properties / language / description
        Previous value: -"Optional programming language to filter results (e.g., 'python', 'javascript', 'go')."New value: +"Optional language filter (e.g. 'python', 'javascript', 'go')."
      • addedInput schema / properties / limit
        Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Alias for 'top_k'; overrides it when provided."
+}
      • changedInput schema / properties / path_prefix / description
        Previous value: -"Optional file path prefix to restrict the search to a specific directory (e.g., 'src/controllers')."New value: +"Optional path prefix filter (e.g. 'src/controllers')."
      • changedInput schema / properties / query / description
        Previous value: -"The natural language search term or description of the code to find."New value: +"Natural language description or exact symbols to find."
      • changedInput schema / properties / repo / description
        Previous value: -"Optional repository name to filter results."New value: +"Optional repository name filter."
      • changedInput schema / properties / top_k / description
        Previous value: -"Maximum number of results to return (integer between 1 and 50). Defaults to 5."New value: +"Max results, 1-50. Defaults to 5."
    • Removedatlas_status
  3. 4 tool updatesv1.0.0
    • First observedatlas_index
    • First observedatlas_map
    • First observedatlas_search
    • First observedatlas_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool serves a clearly distinct purpose: search for finding code, graph for connectivity, brief for orientation, status for diagnostics, and index for building/refreshing the index. Descriptions explicitly cross-reference when to use which tool, eliminating ambiguity.

Naming Consistency5/5

All tools follow a consistent atlas_<noun/verb> pattern with lowercase and underscores. The naming is uniform and predictable, making it easy to infer the function of each tool.

Tool Count5/5

Five tools is well-scoped for a code indexing and search server. Each tool covers a necessary part of the workflow: indexing, status, search, graph exploration, and project briefing, with no redundancy or bloat.

Completeness5/5

The tool set covers the full lifecycle: indexing (atlas_index), health/status (atlas_status), searching (atlas_search), connectivity analysis (atlas_graph), and project orientation (atlas_brief). Missing operations like explicit deletion are unnecessary, as full re-indexing handles updates.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LuisCarlosLopes/codesteer-atlas'

If you have feedback or need assistance with the MCP directory API, please join our Discord server