- Quando um agente de código precisa responder a perguntas estruturais como "como isso funciona?", normalmente ele gasta tokens repetindo dezenas de vezes o ciclo grep → abrir arquivo → rastrear imports
- O
@ttsc/graphentrega ao agente via MCP o grafo de código que o compilador TypeScript já interpretou (o que chama ou depende do quê), fazendo com que ele responda direto pelo grafo em vez de vasculhar arquivos - Dois pontos centrais do design
- Retorna apenas índices – nunca fornece o corpo-fonte; só nomes, arestas, assinaturas e spans
file:line→ o tamanho da resposta não depende do tamanho do repositório, então os tokens não explodem - Chain-of-Thought forçado – como a entrada de uma ferramenta única é um esquema tipado, o agente só pode fazer a requisição depois de preencher
question → draft → review. Otypiacompila isso em esquema+validador e rejeita "pular o raciocínio" no limite da chamada
- Retorna apenas índices – nunca fornece o corpo-fonte; só nomes, arestas, assinaturas e spans
- Resultado: cerca de 10x menos tokens em perguntas abertas, com qualidade de resposta equivalente (8 repositórios × 4 modelos, mediana conservadora)
- Por que usar o compilador: parsers heurísticos como
tree-sitternão conseguem resolver aliases depathsdotsconfig, referências cruzadas em monorepo, symlinks e cadeias de re-export. Só um compilador que já concluiu a resolução real de módulos pode ser preciso → confiável → e fazer o agente responder com confiança e parar - Em comparação com pioneiros:
codegraph/codebase-memory-mcp/serenajá tinham proposto a mesma ideia, mas em perguntas abertas não reduziram tokens ou até consumiram mais do que a baseline (benchmark do autor, com zod: as três ferramentas ficaram entre +22% e +27%) - Limitações: exclusivo para TypeScript (profundidade em vez de abrangência), exige TypeScript v7 (runtime em Go, atualmente RC). Instalação em 4 linhas
Ainda não há comentários.