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., "@codebase-mcp what tech stack does this project use?"
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.
Servidor MCP (Model Context Protocol) Zero-Config para conectar código local con asistentes de IA.
Zero-config CLI that turns any local repository into a Model Context Protocol (MCP) server for Claude, Cursor, Antigravity IDE, and AI agents.
codebase-mcp proporciona a Claude Code, Claude Desktop, Cursor, Antigravity IDE, Windsurf, VS Code y agentes autónomos de IA una visibilidad profunda e instantánea sobre repositorios de código local, sin necesidad de indexadores pesados, bases de datos vectoriales ni configuraciones complejas.
Configuración Cero (Zero-Config): Ejecuta simplemente npx 714-mcp-tool en cualquier carpeta o especifica --path /ruta/al/proyecto.
Motor Híbrido BM25 Inteligente (search_hybrid): Ranqueo de relevancia léxica y conceptual en milisegundos con tolerancia a errores tipográficos (fuzzy search).
E/S Asíncrona de Alto Rendimiento: Operaciones sobre el sistema de archivos no bloqueantes con detección automática de archivos binarios.
Árbol de Proyecto Inteligente (get_project_tree): Genera mapas limpios en texto plano ASCII respetando .gitignore, con soporte para subcarpetas (sub_path).
Búsqueda Instantánea con Filtros (search_codebase): Búsqueda rápida estilo grep con números de línea, snippets, regex (use_regex), filtros de extensión (file_extensions) y subcarpeta (path_pattern).
Esquema e Índice de Símbolos (get_file_outline): Extrae la tabla de contenidos (funciones, clases, interfaces, métodos, encabezados) con números de línea para ahorrar memoria y contexto a la IA.
Análisis de Dependencias e Impacto (get_file_dependencies): Analiza qué librerías importa un archivo y qué otros archivos del proyecto se verán afectados si se modifica.
Inspección de Cambios Git y Diff (get_git_changes): Muestra archivos modificados, staged y diffs de código para revisiones y generación de commits.
Parchado Quirúrgico Seguro (apply_file_patch): Aplica ediciones de código con validación de coincidencia previa para garantizar integridad y evitar alucinaciones.
Lectura Segura de Archivos (read_project_file): Lee archivos completos o rangos de líneas con límites de tamaño y protección contra Path Traversal.
Seguridad Integrada: Bloquea y protege automáticamente archivos sensibles (.env, .pem, id_rsa, credentials.json, secrets.json, .npmrc, .pypirc, etc.).
Diagnóstico de Stack Tecnológico (inspect_tech_stack): Identifica proyectos Node.js, Python, Go, Rust, Java, PHP, Ruby y entornos Docker.
Related MCP server: Repo Interrogator
No necesitas clonar este repositorio manualmente para usarlo. Tu asistente de IA ejecuta codebase-mcp en segundo plano como un proceso local cuando lo necesita.
[ Usuario ] -- "¿Dónde se gestiona la seguridad y qué pasa si la modifico?"
│
▼
[ Asistente IA ] -- (Detecta herramientas de codebase-mcp)
│
├─► 1. Búsqueda híbrida conceptual: search_hybrid(query: "seguridad de credenciales")
│ └─► Retorna: "src/utils/fileSystem.ts (100% Match) -> isSensitiveFile"
│
├─► 2. Análisis de impacto: get_file_dependencies(relative_path: "src/utils/fileSystem.ts")
│ └─► Retorna: "4 archivos dependen de esta función"
│
├─► 3. Edición segura: apply_file_patch(relative_path: "src/utils/fileSystem.ts", target_content: "...", replacement_content: "...")
│ └─► Retorna: "Patched successfully with integrity check"
│
▼
[ Asistente IA ] -- "Se localizó y modificó la función de forma segura verificando su impacto en el proyecto."No requiere instalación previa. Ejecuta directamente usando npx:
npx 714-mcp-toolO especifica la ruta del proyecto explícitamente:
npx 714-mcp-tool --path /ruta/a/tu/proyectoAgrega el servidor a tu archivo de configuración global ~/.gemini/config/mcp_config.json:
{
"mcpServers": {
"codebase-mcp": {
"command": "npx",
"args": ["-y", "714-mcp-tool"]
}
}
}claude mcp add codebase-mcp -- npx -y 714-mcp-toolAbre Cursor Settings -> MCP.
Haz clic en + Add New MCP Server.
Configura: Name: codebase-mcp, Type: command, Command: npx -y 714-mcp-tool.
Añade en claude_desktop_config.json:
{
"mcpServers": {
"714-mcp-tool": {
"command": "npx",
"args": ["-y", "714-mcp-tool"]
}
}
}Herramienta | Parámetros | Descripción |
|
| Búsqueda híbrida inteligente BM25 + Símbolos con ranqueo de relevancia por porcentaje. |
|
| Devuelve la estructura en árbol ASCII del proyecto o subcarpeta respetando |
|
| Busca patrones de texto o regex con filtros opcionales de extensión y carpeta. |
|
| Extrae índice y símbolos (funciones, clases, interfaces, tipos, encabezados) con líneas. |
|
| Análisis de impacto: qué importa este archivo y qué otros archivos del proyecto dependen de él. |
|
| Inspecciona cambios locales de Git (modificados, staged, untracked) y diff para reviews/commits. |
|
| Aplica una edición de código con validación de coincidencia exacta previa. |
|
| Lee el contenido de un archivo de forma segura con números de línea y protección contra binarios. |
| ninguno | Analiza manifiestos del proyecto ( |
codebase-mcp gives Claude Code, Claude Desktop, Cursor, Antigravity IDE, Windsurf, VS Code, and autonomous AI agents instant, deep visibility into your local codebases without indexers, vector databases, or complex setup.
Zero Configuration: Simply run npx 714-mcp-tool in any project folder or specify --path /path/to/project.
Smart BM25 Hybrid Search (search_hybrid): Fast relevance-ranked lexical and symbol search with fuzzy matching in milliseconds.
High-Performance Async I/O: Fully non-blocking asynchronous filesystem operations with automatic binary file detection.
Smart Tree Inspection (get_project_tree): Generates clean ASCII directory maps respecting .gitignore, supporting subfolders (sub_path).
Filtered Instant Search (search_codebase): Fast grep-style search with line numbers, snippets, optional regex, extension filters, and path filters.
Symbol & File Outline (get_file_outline): Extracts declaration table of contents (functions, classes, interfaces, methods, headers) with line numbers to conserve AI tokens.
Dependency & Impact Analysis (get_file_dependencies): Identifies incoming and outgoing dependencies to prevent breaking changes across project files.
Git Changes & Diff Inspection (get_git_changes): Displays uncommitted changes, status, and code diffs for reviews and commit generation.
Surgical Safe Patching (apply_file_patch): Applies surgical edits to files with pre-validation checksum matching.
Safe File Reading (read_project_file): Read specific files or line ranges safely with path traversal protection and binary guards.
Security-First: Automatically redacts and blocks access to sensitive credential files (.env, .pem, id_rsa, credentials.json, secrets.json, .npmrc, .pypirc, etc.).
Multi-Language Tech Stack Diagnostics (inspect_tech_stack): Automatically identifies Node.js, Python, Go, Rust, Java, PHP, Ruby, and Docker setups.
Tool | Parameters | Description |
|
| BM25 + Symbol relevance search with percentage score ranking. |
|
| Returns directory tree for whole project or subfolder respecting |
|
| Searches codebase with optional extension and subfolder filtering. |
|
| Extracts table of contents and declarations with line numbers. |
|
| Reverse dependency and impact analysis across project files. |
|
| Inspects uncommitted Git changes, modified files, and code diff. |
|
| Applies a surgical code patch with exact match verification. |
|
| Safely reads project file contents with line numbers and binary guard. |
| none | Analyzes configuration files to summarize language and framework setup. |
Distributed under the MIT License. See LICENSE for more information.
Returns the directory structure and file tree of the local repository, respecting .gitignore rules.
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Maximum directory depth to scan (default: 4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral context. It discloses the key behavior of respecting .gitignore rules, which is valuable. However, it does not explicitly state that this is a read-only operation, nor does it mention any performance or permission considerations. It is adequate but not rich.
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 a single, front-loaded sentence with no filler. Every word contributes to the semantic meaning, and it immediately states what the tool does.
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?
For a simple tool with one optional parameter and no output schema, the description effectively communicates the output and key filtering behavior. It does not explain the return format in detail, but 'directory structure and file tree' adequately describes the result. It misses only a few nuances like hidden files or symlinks, but overall it is sufficient.
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%, and the only parameter max_depth is well-described in the schema ('Maximum directory depth to scan (default: 4)'). The tool description adds no additional nuance about this parameter, so the baseline of 3 applies.
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 function: 'Returns the directory structure and file tree of the local repository.' This uses a specific verb and resource, and the 'respecting .gitignore rules' clause adds scope. It is well-distinguished from siblings like search_codebase, read_project_file, and inspect_tech_stack.
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 implies usage—it returns the repo structure—but does not explicitly state when to use this over alternatives. No mention of 'if you need to search use...' or 'use this before read_project_file to locate files.' Usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes package files (package.json, Cargo.toml, requirements.txt, Dockerfile, etc.) to report project dependencies, frameworks, and setup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'analyzes' package files, suggesting a non-destructive operation, but it does not explicitly confirm it won't modify files or require special permissions. There is no disclosure of side effects or limitations.
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?
A single, focused sentence states the action, resources, and output. Every part earns its place, with no fluff or repetition. Front-loaded with the verb and key object.
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 a 0-parameter tool with no output schema, the description adequately explains what it does and what it reports. It lists specific file types to inspect, which clarifies scope. It could add a note about behavior when no package files are found, but that is a minor gap.
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?
The tool has zero parameters and schema coverage is 100% with an empty properties object. The description therefore needs no parameter explanation, and the baseline of 4 applies. The examples of file types give context, but no additional parameter semantics are needed.
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 uses a specific verb 'Analyzes' with clear resources (package files) and outputs (dependencies, frameworks, setup). It distinguishes itself from siblings like get_project_tree or search_codebase by focusing on package files rather than general file structure or code search.
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 implies usage when one needs the tech stack, but it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or conditions. No sibling tool is referenced, so guidance is only inferred from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the contents of a specific file within the project safely with line numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| end_line | No | Optional end line number (inclusive) | |
| start_line | No | Optional start line number (1-based) | |
| relative_path | Yes | Relative path of the file to read (e.g. 'src/index.ts') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only mentions 'safely' without elaborating on permissions, error handling, or output format. It does not disclose behaviors like handling non-existent files or line range validity. Given the absence of annotations, the description does not adequately cover behavioral traits.
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 a single concise sentence that states the purpose without unnecessary words. It is front-loaded with the primary action.
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?
The tool is simple (read a file) and has a complete schema, but the description lacks details on the output format (does it return the full text with line numbers? only the requested line range?) and error behavior. Without an output schema, the description should clarify these aspects.
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 all parameters. The description adds the phrase 'with line numbers' and 'within the project', which slightly enhances context but does not explain start_line/end_line behavior beyond what the schema states.
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 uses a clear verb 'reads' with a specific resource ('contents of a specific file within the project') and mentions line numbers. This distinguishes it from sibling tools like get_project_tree (tree structure), search_codebase (searching), and inspect_tech_stack (tech stack).
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 does not explicitly state when to use this tool over the siblings or provide exclusions. It implies usage for reading file contents, but lacks clear contextual guidance such as 'use for viewing file source'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the codebase for a text pattern or regular expression, returning matching files, line numbers, and snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text or regex pattern to search for | |
| use_regex | No | If true, treats the query as a Regular Expression (default: false) | |
| max_results | No | Maximum number of results (default: 30) |
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 only mentions the basic output and does not disclose important traits such as case sensitivity, whether it searches filenames or content, or limitations like respecting .gitignore. This is a significant gap for a search tool.
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 a single, front-loaded sentence that efficiently conveys the tool's function and output. Every word earns its place, and there is no fluff or repetition.
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?
The tool is simple, the schema covers all parameters, and the description explains the return format. While there is no output schema, the description mentions the key output components. It lacks minor details like result ordering or default limits, but the overall description is sufficient for a straightforward search tool.
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?
The input schema already provides 100% coverage for all parameters, including descriptions for query, use_regex, and max_results. The description adds no new meaning beyond the schema, so 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 verb 'searches', the resource 'codebase', and the scope 'text pattern or regular expression'. It also mentions the output format (files, line numbers, snippets), which distinguishes it from sibling tools like get_project_tree or read_project_file.
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 makes the purpose clear, so it's obvious when this tool should be used, but it does not explicitly compare against alternatives or state when not to use it. No explicit exclusion or alternative guidance is provided, unlike the high-calibration example.
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.
v1.1.0get_project_treeinspect_tech_stackread_project_filesearch_codebaseEach tool targets a distinct aspect of codebase exploration: tree structure, content search, file reading, and dependency analysis. There is no overlap in purpose or output.
All tool names follow a clear verb_noun pattern with snake_case (get_project_tree, search_codebase, read_project_file, inspect_tech_stack). The verbs are distinct and accurately describe the action.
Four tools is well-scoped for a codebase exploration server. Each tool provides a necessary and non-redundant capability, without being overly sparse or bloated.
The set covers common read-only codebase tasks: structural overview, searching, reading files, and identifying tech stack. A minor gap is the lack of direct directory-level file listing or metadata, but the overall surface is sufficient for typical exploration.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Misa714/codebase-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
