Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Codebase Symbols Server analyze the codebase at /home/user/projects/api-service"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Um servidor MCP (Model Context Protocol) que analisa sua codebase completa e extrai todos os símbolos (funções, classes, métodos, interfaces, etc.) em um markdown otimizado para LLMs.
🔍 Análise Completa: Varre recursivamente toda a codebase
🚫 Respeita .gitignore: Ignora automaticamente arquivos/pastas do .gitignore
🌐 Multi-linguagem: Suporte para 10+ linguagens de programação
📊 Símbolos Detalhados: Extrai funções, classes, métodos, interfaces, types, enums, etc.
🎯 LLM-Ready: Markdown otimizado para economia de tokens e máxima clareza
⚡ Uma Única Requisição: Entenda toda a estrutura do código instantaneamente
Related MCP server: Scantool - File Scanner MCP
JavaScript / TypeScript (.js, .jsx, .ts, .tsx, .mjs, .cjs)
Python (.py)
Java (.java)
Go (.go)
Rust (.rs)
C / C++ (.c, .cpp, .cc, .h, .hpp)
PHP (.php)
Ruby (.rb)
C# (.cs)
Swift, Kotlin, Scala, R
npm installnpm run buildAdicione ao seu arquivo de configuração do Claude Desktop (claude_desktop_config.json):
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"codebase-symbols": {
"command": "node",
"args": [
"C:\\Users\\darci\\desenvolvimento\\MyCode MCP\\dist\\index.js"
]
}
}
}Configure o servidor apontando para:
node C:\Users\darci\desenvolvimento\MyCode MCP\dist\index.jsApós configurar o servidor no seu cliente MCP (como Claude Desktop), você pode usar a tool analyze_codebase:
No Claude Desktop ou outro cliente MCP:
Analise a codebase em C:\meu\projetoO servidor irá:
✅ Carregar o .gitignore do projeto
✅ Varrer todos os arquivos de código
✅ Extrair símbolos de cada arquivo
✅ Gerar markdown estruturado
# Codebase Structure
**Base Path:** `C:\meu\projeto`
**Total Files:** 42
**Total Symbols:** 328
---
## 📁 src/services
### 📄 `userService.ts`
**Path:** `src/services/userService.ts`
**Symbols:** 8
**Classes:**
- `UserService` (Line 10)
```typescript
export class UserService {Methods:
getUser (Line 15)
createUser (Line 23)
updateUser (Line 31)
Functions:
validateEmail (Line 45)
export function validateEmail(email: string): boolean {
## 🎨 Por Que Isso é Útil?
### Para LLMs
- **📉 Economia de Tokens**: Não precisa enviar o código inteiro, apenas os símbolos
- **🧠 Contexto Completo**: LLM entende toda a estrutura de uma vez
- **🎯 Precisão**: Pode navegar e entender arquiteturas complexas
- **⚡ Performance**: Uma única requisição vs. múltiplas
### Para Desenvolvedores
- **📚 Documentação Automática**: Overview instantâneo da codebase
- **🔍 Code Navigation**: Encontre símbolos e suas localizações rapidamente
- **📊 Análise Arquitetural**: Visualize a estrutura do projeto
- **🤖 AI-Assisted Coding**: LLMs podem dar melhores sugestões com contexto completo
## 🚀 Scripts Disponíveis
```bash
# Compilar o projeto
npm run build
# Compilar e watch para mudanças
npm run watch
# Iniciar o servidor (após compilar)
npm startpath (string, obrigatório): Caminho absoluto para o diretório da codebase a analisar
Markdown estruturado contendo:
Estatísticas gerais (total de arquivos, símbolos)
Estrutura de diretórios
Para cada arquivo:
Path relativo
Símbolos encontrados (classes, funções, etc.)
Números de linha
Assinaturas de código
Analise a codebase em C:\projeto\backend e me diga se há algum padrão inconsistenteMe explique a arquitetura do projeto em C:\meu\appAnalise C:\legacy\code e sugira como modernizar a estruturaCrie documentação técnica baseada na codebase em C:\api✅ Roda localmente na sua máquina
✅ Nenhum código é enviado para servidores externos
✅ Apenas símbolos/estrutura são extraídos, não o código completo
✅ Respeita .gitignore para não expor arquivos sensíveis
MIT
Desenvolvido para tornar a análise de código por LLMs mais eficiente e poderosa! 🚀
Analyzes a codebase and returns a comprehensive LLM-optimized markdown with all symbols (functions, classes, methods, interfaces, types, etc.) and their file paths. Respects .gitignore rules. Perfect for giving LLMs complete understanding of code structure in a single request.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the codebase directory to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: returns comprehensive markdown, respects .gitignore rules, and is optimized for LLMs. However, it doesn't address potential limitations like performance characteristics, error conditions, or what happens with invalid paths. It provides useful context but lacks complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that each serve distinct purposes: the first describes the core functionality, the second provides usage context. It's front-loaded with the main purpose. While efficient, it could be slightly more structured by explicitly separating functional description from usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (codebase analysis), no annotations, and no output schema, the description does a good job covering the essential aspects: what it does, what it returns, and key behavioral constraints (.gitignore). However, it doesn't describe the output format in detail (beyond 'LLM-optimized markdown') or potential limitations, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single 'path' parameter well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (it doesn't mention the path parameter at all). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('analyzes', 'returns') and resources ('codebase', 'LLM-optimized markdown with all symbols'). It explicitly distinguishes from the sibling tool 'read_codebase' by emphasizing comprehensive analysis versus simple reading, mentioning specific symbol types and .gitignore handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Perfect for giving LLMs complete understanding of code structure in a single request'), but doesn't explicitly state when NOT to use it or mention the sibling 'read_codebase' as an alternative. It implies usage for comprehensive analysis rather than basic reading, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the full content of all code files in a directory respecting .gitignore rules and returns in a structured format. WARNING: This tool can generate very large responses, use on smaller directories or specific subdirectories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the codebase directory to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that the tool respects .gitignore rules and warns about potentially very large responses. It doesn't cover other aspects like error handling or performance characteristics, but provides key operational guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core functionality, the second provides critical usage warning. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (reading entire codebases) and lack of annotations/output schema, the description provides good coverage of key behavioral aspects but doesn't explain the 'structured format' of returns or error conditions. It's mostly complete but has some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'path' parameter fully. The description adds no additional parameter information beyond what the schema provides, maintaining the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Reads the full content of all code files'), the resource ('code files in a directory'), and scope ('respecting .gitignore rules'). It distinguishes from the sibling 'analyze_codebase' by focusing on reading content rather than analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use ('use on smaller directories or specific subdirectories') due to the warning about large responses. However, it does not explicitly mention when NOT to use it or name alternatives like the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
analyze_codebaseread_codebaseThe two tools have distinct primary purposes: analyze_codebase focuses on extracting symbols and structure for LLM understanding, while read_codebase returns full file content in a structured format. However, both involve reading codebases with .gitignore respect, which could cause some confusion about when to use each, though their descriptions clearly differentiate between symbol analysis vs. full content retrieval.
Both tools follow a consistent verb_noun pattern with snake_case naming (analyze_codebase and read_codebase). The verbs 'analyze' and 'read' are distinct yet related, maintaining a predictable and readable convention throughout the tool set.
With only 2 tools, the server feels thin for a codebase symbols domain, as it might lack operations like filtering symbols, updating analyses, or handling specific file types. While the tools cover core reading and analysis, the count is borderline minimal for typical MCP server scopes, which often include 3-15 tools for comprehensive functionality.
The server provides basic read and analyze operations, but there are notable gaps for a symbols-focused domain. Missing tools might include querying specific symbols, updating symbol databases, or handling incremental changes, which could limit agent workflows. However, the existing tools cover fundamental needs for codebase understanding, allowing agents to work around some limitations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/klimadev/MyCodeKit-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
