O que é o Model Context Protocol (MCP)?
O Model Context Protocol (MCP) é um protocolo aberto de comunicação bidirecional criado para padronizar a forma como Modelos de Linguagem (LLMs), rodando em clientes como editores de código (Cursor, VS Code, Claude Desktop, Cline), interagem de forma segura com fontes de dados e ferramentas locais ou remotas.
Em vez de cada LLM ou IDE escrever integrações proprietárias para ler arquivos, pesquisar em bancos de dados ou executar comandos, eles atuam como Clientes MCP genéricos que se conectam a um ou mais Servidores MCP por canais estruturados.
Como o protocolo funciona na prática?
O ciclo de vida de uma conexão MCP local é simples, robusto e estruturado em 3 fases principais controladas pelo host (a IDE):
Inicialização (Handshake)
O cliente inicia o processo do servidor e troca informações de capacidades (versão do protocolo, ferramentas e recursos disponíveis).
Descoberta (Listing)
O cliente pergunta ao servidor:
"Quais ferramentas você expõe?". O Atlas responde com a
assinatura e descrição de suas 7 ferramentas (ex:
atlas_search, atlas_context,
atlas_expand, atlas_graph).
Execução (Tool Call)
Quando a IA precisa de informações do repositório, envia um JSON-RPC chamando uma tool. O Atlas processa, consulta o LanceDB localmente e retorna o JSON estruturado.
Conceitos Primitivos do MCP
- Tools (Ações): Funções executáveis com argumentos declarados que a IA pode invocar. Possuem schemas definidos via Pydantic para validação automática de entrada.
-
Resources (Dados passivos): URIs que servem como
arquivos ou streams somente-leitura de dados (ex: o Atlas expõe o
resource
atlas://statuscontendo metadados de diagnóstico). - Prompts (Templates): Modelos de prompts pré-configurados que ajudam o usuário a estruturar fluxos complexos de chat.
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "atlas_search",
"arguments": {
"query": "sistema de autenticação JWT",
"top_k": 3
}
},
"id": 42
}
stderr,
impedindo a corrupção do JSON-RPC!
O Pipeline de Indexação do Atlas
Para responder a buscas semânticas instantâneas sem gastar tokens, o
CodeSteer Atlas constrói um índice vetorial, textual e um grafo de
conectividade na pasta local .code-index. O processo é
orquestrado por index_workspace() em
indexer.py e segue 6 fases ponderadas:
Scan
Varredura recursiva do workspace (ou subpastas em
--paths). Ignora node_modules,
.git, .atlasignore e arquivos > 2
MB.
Hash
Compara mtime + size e sha256 com
manifest.json. Fast path evita reler arquivos
inalterados.
Chunk
Parse AST (Tree-sitter) ou estratégias textuais. Extrai
símbolos, imports e rationale refs (DECISAO-XXX).
Embed
Vetores 384d com all-MiniLM-L6-v2 via
fastembed — apenas chunks novos ou alterados.
Persist
Grava no LanceDB, atualiza FTS (BM25) e o
manifest.json (incremental ou rebuild com
--full).
Graph
Atualiza graph.json/graph.html com a
estratégia mais barata possível: pula se nada mudou, faz rebuild
incremental quando só código já indexado foi alterado, ou
reconstrói tudo nos demais casos.
Depois do Graph, fases
opt-in ou sempre-locais podem complementar o
índice: SCIP (ATLAS_SCIP=1) emite arestas
calls; a camada semântica
(ATLAS_SEMANTIC=1) grava semantic.json; a
história de Git (sem flag) publica history.json na
janela de 100 commits / 24 meses.
Indexação Incremental
A indexação padrão é 100% incremental baseada em arquivos. Ela
compara o hash SHA-256 atual de cada arquivo com o mapa
persistido em manifest.json.
- Novo arquivo: Chunking → Embeddings → Salva no banco.
- Arquivo alterado: Remove chunks antigos associados ao caminho no LanceDB → Gera novos chunks → Salva.
- Arquivo deletado: Apenas remove os chunks antigos correspondentes no LanceDB.
-
Forçar Reconstrução: O parâmetro
--fullreconstrói completamente a tabela, sobrescrevendo todo o banco.
O que fica em .code-index/
manifest.json
Hashes sha256, metadados, git HEAD, versão do índice. Usado por
atlas_status e indexação incremental.
lancedb/
Tabela chunks com vetores + texto. Alimenta
atlas_search (híbrido).
graph.json
Grafo derivado: arquivos, símbolos, docs, imports e cites.
Consultado por atlas_graph.
graph.html
Viewer offline com busca, filtros e pan/zoom. Abra via
file:// — caminho em
graph_viewer_path.
brief.json
Briefing ranqueado (identidade, camadas, entrypoints, hubs).
Consumido por atlas_brief.
semantic.json
Sidecar da camada opt-in (ATLAS_SEMANTIC=1):
propósito por símbolo e sumários. Ausente no default.
history.json
Ponteiro da janela local de Git (sem flag de ambiente). Hits
type="commit" e recent_history no
intent debug.
Workspace com várias pastas ou repos
Você pode indexar subpastas específicas com
--paths repetido ou via MCP
paths=["frontend", "backend"]. Para workspaces com
múltiplos repositórios git aninhados, a abordagem recomendada é
um único .code-index na pasta pai.
✓ Suportado
-
Indexar várias subpastas:
-p frontend -p backend - Filtrar busca:
path_prefix="backend/" - Indexação incremental por subárvore
- Pastas
.gitignoradas automaticamente
⚠ Limitações atuais
-
MCP usa um índice por processo — não mergeia
dois
.code-index -
Campo
reponos chunks = nome da pasta workspace, não cada repo filho -
is_stalesó reflete git na raiz do workspace
uv run atlas-index --workspace . --paths src --paths docs --paths cognitive-base
# Via MCP (síncrono quando paths está definido)
atlas_index(paths=["src", "docs"])
Onde fica o .code-index?
O servidor MCP precisa localizar a pasta .code-index do
projeto antes de buscar ou indexar. A resolução segue uma cadeia de
prioridade fixa (DECISAO-002). O campo
index_resolution retornado por
atlas_status indica qual mecanismo foi usado — útil
para diagnosticar plugins globais iniciados com CWD diferente da
raiz do projeto (ex.: HOME).
-
--index-dir— argumento de linha de comando do servidor (index_resolution: "cli-arg"). -
ATLAS_INDEX_DIR— variável de ambiente explícita ("env"). -
Discovery ascendente a partir do CWD — sobe
diretórios procurando uma pasta
.code-indexexistente, estilo.git("discovery"). -
Raiz informada pelo editor —
CLAUDE_PROJECT_DIR(Claude Code) ouWORKSPACE_FOLDER_PATHS(Cursor/VS Code), quando o CWD do plugin não é a raiz do projeto ("editor-project-dir"ou"editor-project-dir-fallback"). -
MCP roots (upgrade na 1ª tool call) — se a
resolução de startup caiu em fallback, a primeira chamada a uma
tool consulta
roots/listdo cliente MCP, localiza ou aponta o índice para a raiz real do workspace ("roots"ou"roots-fallback"). Cobre plugins globais (Copilot, Cursor, Kiro) sem configuração por projeto. -
Fallback final —
.code-indexrelativo ao CWD ou à raiz do editor ("cwd-fallback").
atlas_status e verifique
index_resolution e index_path se a busca
retornar índice inexistente ou vazio.
Reindex automático em background
Ao iniciar o servidor MCP (atlas-serve), se já existir
um índice local, o Atlas dispara uma
reindexação incremental em subprocesso — sem
bloquear o canal stdio JSON-RPC. Operações pesadas (LanceDB, Tantivy
FTS, ONNX) rodam fora do processo do servidor para não congelar
chamadas MCP.
-
Lock de reindex: apenas um processo reindexa por
vez;
atlas_statusexpõereindexing: trueenquanto o lock estiver ativo. -
Log: saída em
.code-index/background_reindex.log, com cabeçalhos timestamped por execução. -
atlas_indexassíncrono: indexação do workspace inteiro ou comfull=truetambém roda em background e retorna imediatamente comstatus,pidelog_path. Indexação de subpastas específicas (pathsnão vazio,full=false) permanece síncrona.
Indexação de Código com parsing AST
Diferente de sistemas ingênuos de busca que quebram o código baseados em números de linhas fixas (o que pode cortar uma função ao meio e quebrar sua coerência lógica), o CodeSteer Atlas utiliza um analisador sintático completo: o Tree-sitter.
O analisador lê o código-fonte de linguagens como Python, JavaScript, TypeScript, Go, Java, C#, C++, Rust, Kotlin, etc., e monta uma Árvore Sintática Abstrata (AST).
Características da indexação AST
-
Granularidade Semântica: O gerador de chunks
(
ASTChunker) extrai apenas nós relevantes de escopo como classes (class), funções (function) e métodos (method). -
Nomes Hierárquicos: Chunks aninhados recebem
nomenclatura estruturada refletindo o escopo, facilitando a
identificação (ex: um método dentro de uma classe vira
ClasseExemplo.nome_do_metodo). -
Fallback Seguro: Se o arquivo não contiver
símbolos identificáveis (scripts sequenciais, arquivos de
configuração), o módulo cria um único chunk do tipo
modulecontendo todo o arquivo. - Truncamento Inteligente: Quando um chunk excede o limite estimado do modelo (~1000 caracteres), o Atlas preserva as 7 primeiras linhas (contendo assinatura e docstring) e as 3 últimas linhas (retorno), inserindo uma marcação de truncamento no meio. Isso economiza contexto e mantém a assinatura visível para a IA.
Indexação de Texto e Documentos
Arquivos de documentação (como Markdown ou arquivos de texto puro)
ou scripts sem estrutura orientada a objetos (como arquivos SQL ou
JSON) não possuem uma hierarquia clássica de classes e métodos. Por
isso, o ASTChunker adota estratégias específicas e
otimizadas para cada tipo de formato:
Estratégias de Chunking por Formato
| Tipo de Arquivo | Estratégia Principal | Tipo de Escopo | Comportamento em Blocos Grandes (>1000 caracteres) |
|---|---|---|---|
Código AST.py, .js, .go, .java, .cs...
|
Nós da árvore sintática (Classes, Funções, Métodos) via Tree-sitter |
class, method,
function
|
Truncamento inteligente: preserva 7 linhas iniciais + 3 finais, cortando o meio. |
Markdown.md |
Divisão estrutural baseada em cabeçalhos (#,
##, ###)
|
section |
Quebra recursiva em múltiplos sub-chunks divididos por
parágrafos (\n\n).
|
SQL.sql |
Identificação de declarações (Statements) via parser Tree-sitter SQL |
table, view, query...
|
Statements imensos são cortados em múltiplos blocos respeitando as quebras de linha. |
Texto / Outros.txt, .xml, .json, .yaml...
|
Quebra baseada em parágrafos ou linhas estruturadas | chunk |
Agrupamento sequencial de parágrafos acumulando até o limite de 1000 caracteres. |
Amostra de Extensões Suportadas (SUPPORTED_EXTENSIONS)
Referências cruzadas em Markdown (busca enriquecida)
Além de indexar seções Markdown por cabeçalhos, o
atlas_search enriquece resultados
language=="markdown" com o campo opcional
markdown_references — sem reindexar nem alterar o
schema LanceDB. O enriquecimento é feito em tempo de busca a partir
do conteúdo do chunk.
-
Links padrão:
[texto](destino.md)e[texto](destino.md#secao) -
Wikilinks Obsidian:
[[destino]],[[destino|alias]],[[destino#Secao]],![[embed]] -
Resolução de wikilinks "bare": nomes sem path
(ex.:
[[mcp-server]]) são resolvidos globalmente contra o mapa de arquivos.mddomanifest.json; ambiguidade retorna lista decandidates. -
Âncoras: quando o destino está indexado, o campo
resolved_sectionpode mapear#secaoao nome da seção correspondente.
{
"file_path": "docs/architecture.md",
"language": "markdown",
"symbol": "Pipeline de Indexação",
"score": 0.041,
"markdown_references": [
{
"file_path": "docs/mcp-overview.md",
"anchor": "stdio-transport",
"resolved_section": "Transporte stdio"
},
{
"file_path": "docs/obsidian-vault/note.md",
"anchor": null,
"resolved_section": null
}
]
}
Rationale refs em código (grafo + busca)
Comentários estruturados no código viram metadados persistidos no
índice e arestas no grafo. Resultados de
atlas_search podem incluir
rationale_refs apontando para notas de decisão.
-
Cites:
DECISAO-005,DEC-002,ADR-001,RFC-012 -
Anotações:
# WHY:,# NOTE:(ou//,--) -
Wikilinks em comentários: resolvidos contra
arquivos
.mddo manifest
# DECISAO-005: embeddings locais com fastembed
# WHY: manter indexação 100% offline — nenhum código sai da máquina
def encode(self, texts: list[str]) -> list[list[float]]:
...
Grafo de Conhecimento Derivado
Além da busca semântica, o Atlas deriva um
grafo de conectividade a cada indexação. Ele mapeia
relações explícitas entre código, documentação, imports e rationale
— não substitui atlas_search, mas responde perguntas do
tipo "como A se conecta a B?".
atlas_search
Localizar por conceito ou símbolo — busca híbrida vetorial + BM25.
atlas_graph
Explorar hubs, caminhos, vizinhança e raio de impacto
(affected).
atlas_context
Pacote da tarefa (target + intent)
numa chamada, com teto de tokens.
graph.html
Exploração visual offline — pan, zoom, filtros e foco local.
Tipos de nó e aresta
Nós (kind) |
Exemplo | Arestas (kind) |
Significado |
|---|---|---|---|
file, doc |
src/server.py, dec-002.md |
contains |
Arquivo contém símbolo ou seção |
symbol |
index_workspace |
imports |
Import resolvido (Python, JS/TS, Go, Java, C#, …).
origin: "treesitter"
|
commit |
SHA da janela histórica | calls |
Chamada via SCIP (origin: "scip"). Só com
ATLAS_SCIP=1
|
touches |
Commit tocou o símbolo. Não entra em hubs/affected
|
||
section |
Heading markdown | links_to |
Link ou wikilink entre docs |
rationale |
Texto de WHY: / NOTE: |
cites |
Referência DECISAO-XXX no código |
annotates |
Comentário rationale ligado ao símbolo | ||
Tool atlas_graph — quatro modos
Lê o graph.json já gerado —
não reconstrói o grafo. Reindexe com
atlas_index se o grafo estiver ausente (índices <
2.1.0).
Nós centrais
Retorna os nós mais conectados (maior grau). Ideal para descobrir documentos e código “hub” do projeto.
atlas_graph(mode="hubs", top_n=10)
Vizinhança
Resume arquivos, docs citados e rationale ligados a um símbolo, arquivo ou nota.
atlas_graph(mode="explain",
target="index_workspace")
Caminho BFS
Encontra rota entre dois nós (até 10 saltos). Aceita id, label ou sufixo único.
atlas_graph(mode="path",
source="index_workspace",
target="dec-002")
Raio de impacto
BFS reversa: o que quebra se este símbolo mudar. Ignora nós
commit e arestas touches.
atlas_graph(mode="affected",
target="index_workspace")
Visualizador graph.html
Após indexar, abra o HTML autocontido em
.code-index/graph.html. O caminho absoluto aparece em
atlas_status → graph_viewer_path.
- Busca por label ou id de nó
- Clique em nó para focar subgrafo local
- Filtros por tipo de nó e aresta
- Grafos grandes (> 3000 nós): modo hubs-only com opção “Expandir tudo”
-
Debug: adicione
?debug=1na URL
atlas_graph retornar erro de
graph.json ausente, rode
uv run atlas-index --workspace . --full
para regenerar grafo e viewer (requer índice versão 2.1.0+).
Busca Híbrida e Embeddings Locais
Para obter a máxima precisão nas respostas sem perder a velocidade e o contexto sintático, o CodeSteer Atlas utiliza um motor de Busca Híbrida de dois braços paralelos. A busca combina o melhor de duas abordagens:
1. Braço Semântico (Vetor)
Conceito: Busca por similaridade de cosseno nos embeddings gerados.
Modelo: all-MiniLM-L6-v2 local via
biblioteca fastembed (ONNX Runtime, 384 dimensões).
Vantagem: Encontra conceitos equivalentes mesmo
sem palavras-chave idênticas (ex: busca por "inicializar banco"
encontra o método Database.connect()).
2. Braço Léxico (Full-Text Search)
Conceito: Busca de texto completo baseada no algoritmo tradicional BM25 (via Tantivy integrado ao LanceDB).
Mecanismo: Índice invertido clássico construído na coluna de conteúdo dos chunks.
Vantagem: Encontra termos específicos, siglas
de métodos ou strings exatas (ex: buscar por um código de erro
específico como ERR_AUTH_FAILED).
Fusão de Rankings: Reciprocal Rank Fusion (RRF)
Após coletar de forma independente as listas de melhores candidatos
de cada braço (configurado pela constante
CANDIDATES_LIMIT = 50), o Atlas funde os resultados em
um único ranking unificado usando o algoritmo matemático
RRF (Reciprocal Rank Fusion):
Onde c é o chunk de código,
M representa os sistemas de busca (Vetorial e
FTS), rankm(c) é a posição do chunk no
ranking daquele sistema (1-indexed), e k é a
constante de suavização configurada como 60 (RRF_K = 60).
Dessa forma, arquivos que aparecem bem posicionados em ambos os motores ganham prioridade absoluta, garantindo um resultado final superior a qualquer um dos métodos isolados.
Depois do RRF, um rerank lexical reordena o pool por padrão (ATLAS_RERANK=0
desliga toda reordenação, inclusive o Jev opt-in descrito na seção
Jev). ATLAS_RERANK_MODEL troca essa
etapa por um cross-encoder ONNX.
atlas_search(..., structural=true) adiciona um terceiro
braço RRF sobre graph.json. Cada hit traz
match_arms (vector, fts,
graph). Com história indexada, a busca também pode
devolver type="commit".
Jev e entrega compacta (opt-in)
O Jev é o modelo System One da TypeSafe. Recebe a consulta e os candidatos recuperados pelo Atlas e devolve uma avaliação de relevância com score e confiança para cada candidato. A chamada usa a API System One do OpenRouter.
Jev vem desligado. A busca híbrida e o rerank
lexical continuam locais por padrão.
ATLAS_RELEVANCE=1 habilita o Jev;
ATLAS_CONTEXT_OPTIMIZATION=1 ativa o perfil compacto
por padrão. As duas flags são independentes. Configurar uma chave ou
ligar a camada semântica não habilita o Jev.
Recuperação local
O Atlas combina os braços de busca via RRF e aplica o rerank lexical ao pool de candidatos.
Avaliação com Jev
Antes do corte top_k e da junção com commits, o Jev
refina a ordem lexical. Correspondências exatas ficam na frente;
avaliações incertas ou ausentes preservam a posição lexical.
Corte no perfil compacto
Entre os top_k primeiros do pool deduplicado na
ordem Jev, remove avaliações abaixo da metade da escala. Não
repõe a vaga pelo próximo candidato.
Expansão seletiva
O agente usa atlas_expand para ler uma ou duas
referências necessárias por vez, sem nova chamada ao Jev.
Rubrica v2: quatro níveis de evidência
A rubrica padrão é v2, com escala de 0 a 3. Cada nível
tem critérios e exemplos; cada candidato inclui tipo
(kind) e linguagem (language). A avaliação
aceita perguntas em português, nomes exatos e identificadores
parciais.
| Nível | Significado | Exemplo ilustrativo para “onde o config é lido?” |
|---|---|---|
| 0 · Não relacionado | Trata de outro comportamento ou componente. | Função que renderiza HTML. |
| 1 · Menção de passagem | Cita ou usa o conceito sem implementá-lo ou explicá-lo. | Entrypoint que chama o carregador entre várias etapas. |
| 2 · Contexto de apoio | Ajuda a entender o comportamento cuja implementação principal está em outro lugar. | Teste que verifica o carregamento da configuração. |
| 3 · Evidência direta | Define, implementa ou explica diretamente o comportamento consultado. | Função que lê e interpreta o arquivo de configuração. |
ATLAS_RELEVANCE_RUBRIC=v1 volta à rubrica anterior, com
três níveis e escala de 0 a 2. Os limiares são proporcionais à
escala. O campo score publicado em cada resultado da
busca continua sendo o RRF; ele não é substituído pelo score Jev.
O pool em uma chamada
Uma chamada leva o pool inteiro quando cabe em
192 KB (192.000 bytes UTF-8). Só em overflow
podem ocorrer até duas chamadas, com timeout compartilhado de 3
s. Modelo padrão: ~typesafe/jev-latest.
top_k é um teto
No compacto, com Jev avaliado, o corte padrão remove score
abaixo de 1,5 na v2 ou de 1,0 na v1, inclusive
avaliações incertas. Correspondências exatas e candidatos sem
avaliação permanecem. O perfil full não recebe esse
corte.
Falhas preservam a recuperação local
Timeout, erro HTTP ou resposta inválida afetam só o lote
correspondente. Baixa confiança isola o candidato na
reordenação. ATLAS_RERANK=0 desliga toda
reordenação, inclusive a chamada ao Jev.
Corte padrão e seleção conservadora
ATLAS_RELEVANCE_CUT ausente ou 1 habilita
o corte padrão quando Jev e perfil compacto estão ativos. As vagas
cortadas não são repostas nem cedidas a commits; commits só ocupam
vagas que o pool já não preenchia.
omitted.relevance conta os descartes. Sem avaliação
válida, não há corte.
Com ATLAS_RELEVANCE_CUT=0, vale a seleção conservadora:
remove apenas score ≤ 1/8 da escala (0,375 na v2 ou 0,25 na v1) com
confiança ≥ 0,90, permitindo repor a vaga pelo pool. Nos dois modos,
se tudo sair, volta o primeiro candidato do ranking local com
relevance_unconfirmed_fallback.
Entrega compacta (independente do Jev)
ATLAS_CONTEXT_OPTIMIZATION=1 faz
response_profile=default resolver para
compact em atlas_search e
atlas_context: projeção enxuta, deduplicação por
cobertura verificável, orçamento a 70% do teto e referências para
expansão. O bloco budget só aparece quando algo foi
cortado para caber. response_profile=full mantém a
resposta completa.
Em atlas_expand, classes acima de aproximadamente 1.500
tokens, com métodos indexados, abrem como cabeçalho e
outline dos métodos com suas referências. Expanda
apenas os métodos necessários.
ATLAS_EXPAND_OUTLINE=0 volta à classe inteira paginada.
Quando dispensar a chamada ao Jev
O gate fica desligado por padrão.
ATLAS_RELEVANCE_GATE=1 dispensa a chamada quando a
consulta é o nome exato de uma única função, método ou classe
no pool recuperado. Isso não garante unicidade no
repositório inteiro.
ATLAS_RELEVANCE_GATE=identifier dispensa o Jev para
toda consulta-identificador, inclusive nomes parciais ou com pontos.
Essas consultas mantêm a ordem lexical e a promoção do exato, mas
perdem a reordenação Jev e o corte por relevância. O gate economiza
chamadas; pode entregar mais contexto e reduzir a precisão.
ATLAS_RELEVANCE=1, a consulta e os trechos candidatos
são enviados ao OpenRouter. Configure URL e chave próprias, salvo
reuso da configuração semântica quando ela aponta exatamente para o
endpoint HTTPS de chat do OpenRouter. Cada
atlas_search emite uma linha JSON de custo em stderr,
sem consulta, código ou chave. Reinicie o MCP após mudar o
env.
"env": {
"ATLAS_INDEX_DIR": "${workspaceFolder}/.code-index",
"ATLAS_RELEVANCE": "1",
"ATLAS_RELEVANCE_API_URL": "https://openrouter.ai/api/v1/systemone",
"ATLAS_RELEVANCE_API_KEY": "sua-chave-openrouter",
"ATLAS_CONTEXT_OPTIMIZATION": "1"
}
Mescle estas propriedades no env existente. A rubrica
v2 e o corte já são os padrões; não é preciso declará-los. Guarde a
chave em configuração local e não a versione no Git.
Para conferir a configuração, consulte
atlas_status.relevance, incluindo rubric,
cut, gate e egress. Esse
status é estático: ele declara a configuração, sem testar a API.
Consulte a
referência do operador
para medições e contratos detalhados.
As 7 Ferramentas (Tools) do Atlas
O servidor MCP expõe sete ações. Use atlas_brief para
se orientar, atlas_context quando o símbolo já é
conhecido, atlas_search para localizar código,
atlas_expand para abrir trechos de um resultado
compacto, atlas_graph para conectividade, e
atlas_status apenas para diagnóstico explícito.
Busca semântica híbrida (vetorial + BM25) no índice local.
Retorna metadados por padrão; use
include_content=true ou Read nas
linhas indicadas. structural=true adiciona o braço
do grafo. Com ATLAS_CONTEXT_OPTIMIZATION=1,
response_profile=default resolve para compacto;
force full por chamada se precisar do formato
anterior. Hits de Git vêm como type="commit".
Código pode incluir rationale_refs; Markdown inclui
markdown_references.
query,
top_k, path_prefix,
language, include_content,
structural, response_profile
Briefing do projeto: identidade, camadas, entrypoints e hubs.
Chame primeiro, uma vez, em repositório desconhecido.
level=0 ou 1.
level
Pacote da tarefa em uma chamada: vizinhança, impacto, testes
inferidos e camada do brief, sob teto de tokens. Só
intent="debug" inclui recent_history.
Aceita
response_profile
(default/compact/full);
não invoca o Jev.
target,
intent
(edit/debug/review/understand),
response_profile
Abre o código de um resultado compacto por ref —
sem embedding e sem Jev. Comece com uma ou duas refs diretamente
ligadas à pergunta; leia a resposta antes de expandir mais. Até
5 refs por chamada. Pagina símbolos longos com
next_ref.
refs,
include_content
Consulta o grafo derivado (graph.json): hubs,
caminhos BFS, vizinhança e raio de impacto. Use quando a
pergunta for sobre relações, não localização.
Metadados do índice: is_stale,
reindexing, index_resolution,
graph_available, watch,
semantic, relevance,
resolution_coverage. O bloco
relevance declara egresso do Jev. Não é
pré-requisito para busca.
total_chunks,
index_path, git_head_sha
Indexa ou reindexa o workspace. dry_run=true lista
candidatos e, em workspaces grandes (> 200 arquivos
elegíveis), recomenda paths específicos em vez de
indexação completa. Workspace inteiro ou
full=true rodam em background;
paths específicos são síncronos. Atualiza
graph.json/graph.html conforme a
estratégia mais barata (ver fase Graph acima).
workspace,
paths, full, dry_run
phase_durations_s,
graph_strategy, scip_status,
git_history_status, semantic_status
Configuração e variáveis de ambiente
Todas as flags abaixo são opt-in ou de override. Sem elas, o Atlas indexa, busca e serve o grafo 100% local. História de Git não tem variável de ambiente — a janela é teto interno (até 100 commits por arquivo e 24 meses).
| Variável | Default | Efeito |
|---|---|---|
ATLAS_INDEX_DIR |
discovery / .code-index |
Caminho explícito do índice (prioridade 2 da resolução). |
ATLAS_RERANK |
ligado |
0 desliga toda reordenação pós-RRF (lexical,
cross-encoder e Jev).
|
ATLAS_RELEVANCE |
desligado |
1 julga relevância com o modelo Jev (TypeSafe)
antes do top_k, pela API System One do
OpenRouter. Requer URL e chave. Ver seção
Jev.
|
ATLAS_RELEVANCE_API_URL |
derivado / ausente |
Endpoint HTTPS System One
(https://openrouter.ai/api/v1/systemone).
|
ATLAS_RELEVANCE_API_KEY |
ausente |
Chave OpenRouter. Reutiliza
ATLAS_SEMANTIC_API_KEY só quando a URL
semântica é chat HTTPS do OpenRouter.
|
ATLAS_RELEVANCE_MODEL |
~typesafe/jev-latest |
Modelo Jev. Não herda ATLAS_SEMANTIC_MODEL.
|
ATLAS_RELEVANCE_GATE |
desligado |
1 dispensa Jev quando a consulta é símbolo
exato único no pool recuperado.
identifier dispensa para toda
consulta-identificador (menos chamadas, mais tokens).
|
ATLAS_RELEVANCE_RUBRIC |
v2 |
Rubrica do score Jev: v2 (4 níveis com
exemplos, default) ou v1 (3 níveis, mais
barata).
|
ATLAS_RELEVANCE_CUT |
ligado |
Com o Jev e o perfil compacto, faz do top_k um
teto: remove, sem repor, quem tem score Jev abaixo da metade
da escala entre os top_k primeiros;
omitted.relevance conta os cortes.
0 volta à seleção conservadora.
|
ATLAS_CONTEXT_OPTIMIZATION |
desligado |
1 faz
response_profile=default resolver para compacto
em search/context. Independente do Jev.
|
ATLAS_EXPAND_OUTLINE |
ligado |
Classe acima de ~1.500 tokens abre em
atlas_expand como cabeçalho + lista de métodos
com ref. 0 volta à classe inteira
paginada.
|
ATLAS_RERANK_MODEL |
ausente |
Presente → cross-encoder ONNX (slug do modelo; default
Xenova/ms-marco-MiniLM-L-6-v2). Falha:
cross_encoder_unavailable.
|
ATLAS_WATCH |
desligado |
1 observa o workspace e reindexa em subprocesso
após 2 s. Extra:
pip install "codesteer-atlas[watch]". Sem o
extra: watch: "unavailable".
|
ATLAS_SCIP |
desligado |
1 invoca o indexador SCIP e produz arestas
calls. Sem toolchain:
scip_status: "toolchain_missing".
|
ATLAS_SEMANTIC |
desligado |
1 liga propósito por símbolo. Sem origem, o
índice estrutural continua completo.
|
ATLAS_SEMANTIC_LOCAL_URL |
ausente | Endpoint local (segunda origem, depois do sampling MCP). |
ATLAS_SEMANTIC_API_URL |
ausente | URL explícita de API (terceira origem). Sem host default. |
ATLAS_SEMANTIC_API_KEY |
ausente | Só no header da API. |
ATLAS_SEMANTIC_MODEL |
ausente |
Contrato OpenAI-compatible (model +
messages). Sem ele, payload genérico legado.
|
Extra opcional: codesteer-atlas[watch]. Auditoria:
atlas_status → watch,
semantic, relevance,
resolution_coverage.
Princípio Constitucional: Local-First por padrão
Soberania e Privacidade de Código
Em conformidade com o artigo I da constituição do CodeSteer
Atlas (.memory-bank/constitution.md),
no default todo o processamento de código-fonte e
documentação é local e offline. Embeddings (all-MiniLM-L6-v2 via ONNX) e LanceDB
não saem da máquina.
Dois opt-ins podem enviar texto para fora do host: a camada
semântica (ATLAS_SEMANTIC=1) — sampling do cliente
MCP, depois endpoint local, por último API com URL explícita — e
o Jev (ATLAS_RELEVANCE=1), modelo System One da
TypeSafe, que recebe consulta e candidatos pela API System One
do OpenRouter. Sem essas flags, busca e índice permanecem na
máquina. A fronteira é inspecionável em
atlas_status.semantic e
atlas_status.relevance (origin,
egress).
Início rápido (sem clonar o repositório)
Para usar o Atlas em qualquer projeto, basta registrar o servidor
MCP no seu cliente e indexar o workspace uma vez. O pacote roda via
uvx, direto do GitHub — 100% local após o download
inicial das dependências.
1. Indexar o projeto
uvx --from git+https://github.com/LuisCarlosLopes/codesteer-atlas.git \
atlas-index --workspace .
2. Registrar no cliente MCP
Copie o manifest do seu editor (.cursor/mcp.json,
.vscode/mcp.json, etc.) ou instale como plugin:
-
Claude Code:
/plugin install codesteer-atlas -
Copilot CLI:
copilot plugin install LuisCarlosLopes/codesteer-atlas - Kiro: importar Power do GitHub
Pronto para integrar ao seu fluxo de trabalho?
Siga os passos para preparar o Atlas, conectar seu editor e fazer sua primeira busca.