Un poderoso kit de herramientas de análisis de base de código que aprovecha el Protocolo de contexto de modelo (MCP) para la comprensión y transformación del código asistida por IA.
Análisis de código : analice bases de código con árboles de sintaxis abstracta
Generación de contexto : cree información contextual enriquecida para modelos de IA
Integración de herramientas : Construido sobre el SDK de MCP para una integración perfecta de herramientas de IA
Arquitectura extensible : sistema basado en complementos para analizadores personalizados
Related MCP server: Moatless MCP Server
Node.js 18+
NPM 9+
Redis (opcional, solo requerido para entornos de producción)
# Clone the repository
git clone https://github.com/yourusername/mcp-codeanalysis.git
cd mcp-codeanalysis
# Install dependencies
npm install
# Build the project
npm run buildRedis se utiliza para el almacenamiento de sesiones en entornos de producción. Para desarrollo y pruebas, el sistema recurrirá automáticamente a un almacenamiento de sesiones en memoria si Redis no está disponible.
Nota : Existe un problema conocido con la conectividad de Redis, que puede provocar fallos en las operaciones incluso con Redis en ejecución. Consulte la sección "Deuda técnica" en
plan.mdpara obtener más información. Por ahora, puede usar el script./use-memory-session.shpara ejecutar el servidor con el almacén de sesiones de memoria. Para más información, consulte la Guía de solución de problemas de Redis .
Para instalar Redis:
# Ubuntu/Debian
sudo apt-get install redis-server
# macOS
brew install redis
# Windows (using WSL is recommended)
# For native Windows, download from https://redis.io/downloadDe forma predeterminada, la aplicación intenta conectarse a Redis en redis://localhost:6379 . Puede configurar la conexión a Redis mediante variables de entorno:
# Set custom Redis URL
export REDIS_URL=redis://custom-host:6379
# Force memory session store even if Redis is available
export FORCE_MEMORY_SESSION=true# Run in development mode
npm run dev
# Run tests
npm test
# Run linting
npm run lint# Start the MCP server
npm start
# Run CLI tool
node ./tools/mcp-stdio-client.js --task "Analyze dependencies" --files "src/*.ts"Instituto Tecnológico de Massachusetts (MIT)
Un servidor integral de Protocolo de Contexto de Modelo (MCP) para el análisis de código avanzado, que proporciona herramientas y conocimientos a través de una arquitectura extensible.
Análisis básico de código : análisis de sintaxis y estructura
Métricas de código : complejidad, recuentos de líneas y métricas de calidad del código
Análisis de dependencia : visualización de la relación entre paquetes e importaciones
Gráfico de conocimiento : visualización y consulta de relaciones de código
Sistema de memoria : almacene y recupere información sobre bases de código
Visualizaciones : Genera diagramas en múltiples formatos (Mermaid, DOT, ASCII)
Análisis sociotécnico : comprender las relaciones entre el equipo y el código
Análisis de múltiples repositorios : análisis de relaciones entre repositorios
Planificación de la evolución : recomendaciones para mejorar el código
Observación en vivo : supervise los cambios de código en tiempo real
Integración IDE : Herramientas para la integración del editor
Herramientas para desarrolladores : Soporte mejorado para flujos de trabajo de desarrollo asistidos por IA
Node.js 18+
npm o hilo
Redis (opcional para desarrollo, recomendado para producción)
# Clone the repository
git clone https://github.com/your-username/codeanalysis-mcp.git
cd codeanalysis-mcp
# Install dependencies
pnpm install
# Build the project
pnpm buildEl servidor MCP de CodeAnalysis se puede utilizar de dos maneras:
# Start the MCP server
pnpm startEsto inicia el servidor MCP al que puede conectarse cualquier cliente MCP como Claude Desktop, Cursor u otros.
El proyecto incluye una CLI completa para interacción directa:
# Get help
pnpm run cli --help
# Analyze a repository or directory
pnpm run cli analyze repo ./src
# Check code quality
pnpm run cli quality analyze ./srcEl proyecto incluye herramientas especiales diseñadas para mejorar el desarrollo asistido por IA:
# Generate code context for AI assistants
node tools/ai-dev-helper.js --task="Implement new feature" --search="related functionality"
# Run example client
node examples/dev-tools-client.jsConsulte la Guía de herramientas para desarrolladores para obtener información detallada.
# Analyze a local directory
pnpm run cli analyze repo ./src
# Analyze a specific file
pnpm run cli analyze file ./src/server.ts# Get code metrics with function details
pnpm run cli metrics analyze ./src --functions
# Save metrics to a file
pnpm run cli metrics analyze ./src -o metrics-report.json# Analyze dependencies in Mermaid format
pnpm run cli dependencies analyze ./src -f mermaid -o deps.mmd
# Visualize dependencies
pnpm run cli visualize dependencies -p ./src --format mermaid# Run quality analysis
pnpm run cli quality analyze ./src
# Generate HTML report
pnpm run cli quality analyze ./src --html -o quality-report.html# Build knowledge graph
pnpm run cli knowledge build ./src
# Query the knowledge graph
pnpm run cli knowledge query ./src "type:function AND complexity>5"
# Export as diagram
pnpm run cli knowledge export ./src -f mermaid# Store an insight
pnpm run cli insights store -r ./src -t code-pattern -c "Refactoring opportunity"
# Retrieve insights
pnpm run cli insights retrieve -r ./src# Prepare context for AI interactions
node tools/ai-dev-helper.js --task="Fix authentication bug" --files="src/auth/*.ts" --search="login"
# Use with AI prompts
# Copy content from the generated ai-context.json file into your AI assistant prompt
# or use the template in templates/ai-prompt-template.mdEl proyecto sigue la arquitectura MCP con estos componentes:
Servidor MCP : Implementación del servidor central que utiliza el protocolo MCP
Características de análisis : Capacidades de análisis de código modular
CLI : Interfaz de línea de comandos para interacción directa
Capa de transporte : mecanismo de comunicación (stdio por defecto)
Este servidor es compatible con cualquier cliente compatible con MCP, incluidos:
Aplicación de escritorio Claude
Editor de cursores
Continuar
Otras herramientas compatibles con MCP
Los comandos aceptan rutas en varios formatos:
Directorio local: ./src o /absolute/path/to/dir
Archivo local: ./src/file.ts o /path/to/file.ts
URL del repositorio: https://github.com/username/repo
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
Este proyecto implementa herramientas con estado para el SDK del Protocolo de Contexto de Modelo (MCP), proporcionando un marco para crear herramientas que mantienen el contexto entre invocaciones.
La arquitectura de gestión estatal está organizada en varios componentes modulares:
src/state/
├── helpers/
│ └── statefulTool.ts # Main entry point for stateful tool creation
├── machines/
│ └── toolMachine.ts # XState machine for tool execution flow
├── services/
│ ├── toolService.ts # Core execution service for tools
│ ├── redisToolExecutionService.ts # Distributed execution service
│ ├── redisSessionStore.ts # Redis-based session persistence
│ └── types.ts # Shared type definitionsstatefulTool.ts )El punto de integración central con el SDK de MCP, que proporciona:
Registro de herramientas con gestión de sesiones
Formato de respuesta compatible con MCP
Gestión de sesiones en memoria
Funciones auxiliares para el acceso y la manipulación de sesiones
// Creating a stateful tool with state persistence
createStatefulTool(server, "my-tool", schema, handler);
// With description
createStatefulTool(server, "my-tool", "My stateful tool", schema, handler);toolMachine.ts )Máquina de estados basada en XState que define el flujo de ejecución de las herramientas:
Transiciones de estado (inactivo, herramienta seleccionada, parámetros establecidos, en ejecución, etc.)
Gestión del contexto para parámetros, resultados e historial
Manejo de errores y rutas de recuperación
Este componente delega la gestión de la sesión a la implementación de statefulTool.
toolService.ts )Servicio de ejecución central que coordina las transiciones del estado de la herramienta:
Gestiona la selección de herramientas, la validación de parámetros y la ejecución.
Realiza un seguimiento del historial de ejecución
Maneja resultados y errores de ejecución
types.ts )Definiciones de tipos compartidos que garantizan la coherencia en todo el sistema de gestión estatal:
SessionData: Estructura para almacenar el estado de la herramienta
SessionStore: Interfaz para implementaciones de almacenamiento de sesiones
ExecutionResult: Formato de respuesta estándar para herramientas
La arquitectura se integra con el SDK de MCP mediante:
Ampliación del patrón de registro de herramientas con gestión de estados
Mantener la compatibilidad con el formato de respuesta de MCP
Proporcionar seguimiento de sesiones y contexto para operaciones con estado
import { createServer } from "@modelcontextprotocol/sdk";
import { createStatefulTool } from "./state/helpers/statefulTool";
import { z } from "zod";
const server = createServer();
// Register a stateful tool
createStatefulTool(
server,
"counter",
"A tool that maintains a count between invocations",
{
action: z.enum(["increment", "decrement", "reset"]),
},
async (params) => {
// Get session ID from params (or a new one will be created)
const sessionId = params.sessionId;
// Process the action
let count = 0;
// Tool logic with state manipulation...
return { count };
}
);
server.listen(3000);Para entornos distribuidos, las implementaciones basadas en Redis proporcionan:
Persistencia de la sesión tras reinicios del servidor
Bloqueo distribuido para acceso concurrente
Limpieza de sesión basada en TTL
Manejo de errores para problemas de red/conexión
Los componentes incluyen conjuntos de pruebas completos para verificar:
Transiciones de estado de la herramienta
Gestión de sesiones
Manejo y recuperación de errores
Formato de respuesta
Operación distribuida (con Redis)
El servidor MCP de CodeAnalysis proporciona herramientas especializadas para el desarrollo asistido por IA. Estas herramientas ayudan a recopilar el contexto del código que puede alimentarse a los sistemas de IA para una asistencia más eficaz.
El repositorio incluye varios scripts de cliente en el directorio tools/ :
Cliente HTTP ( tools/http-client.js ): se conecta al servidor MCP a través del transporte HTTP (predeterminado).
node tools/http-client.js --task "Your task description" --files "src/features/*.ts" --search "session"Cliente sin procesar ( tools/mcp-raw-client.js ): un cliente más simple que solo captura información del servidor.
node tools/mcp-raw-client.js --task "Your task description"Cliente simple ( tools/simple-client.js ): se comunica con el servidor a través de stdio.
node tools/simple-client.js --task "Your task description" --files "src/features/*.ts"Todos los scripts de cliente generan un archivo ai-context.json en la raíz del proyecto. Este archivo contiene información valiosa sobre el código base que puede compartirse con los asistentes de IA para proporcionar respuestas más informadas.
Hay una plantilla de solicitud para asistentes de IA disponible en templates/ai-prompt-template.md . Esta plantilla ayuda a estructurar las solicitudes a los asistentes de IA con el contexto adecuado de las herramientas MCP.
El servidor MCP admite dos modos de transporte:
Transporte HTTP (predeterminado): Se ejecuta en el puerto 3000 de forma predeterminada. Ideal para arquitecturas cliente-servidor.
Transporte de Stdio : Para la comunicación directa entre procesos. Configure la variable de entorno STDIO_TRANSPORT=true para habilitarla.
El análisis de código MCP ahora cuenta con una arquitectura de almacenamiento de sesiones modular con detección automática de backend:
Almacenamiento flexible : cambia automáticamente entre Redis y almacenamiento en memoria
Apto para desarrollo : Ejecútelo sin Redis durante el desarrollo
Listo para producción : utilice Redis para la persistencia en entornos de producción
Retroceso automático : se recurre elegantemente al almacenamiento de memoria cuando Redis no está disponible
Para obtener más detalles, consulte la documentación de Arquitectura del almacén de sesiones .
Node.js 18+
npm o hilo
Redis (opcional para desarrollo, recomendado para producción)
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file | |
| fileContent | Yes | Content of the file | |
| line | Yes | Cursor line position (1-based) | |
| column | Yes | Cursor column position (1-based) | |
| context | Yes | Context around cursor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | No | URL of the repository to analyze (e.g., 'https://github.com/username/repo') | |
| fileContent | No | Source code content to analyze directly instead of from a repository | |
| language | No | Programming language of the code (e.g., 'javascript', 'python', 'typescript', 'rust') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Files to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryPath | Yes | Path to the repository to analyze | |
| includeFiles | No | Include file-level metrics in the output | |
| includeFunctions | No | Include function-level metrics in the output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryPath | Yes | Path to the repository to analyze | |
| includePaths | No | Patterns of files to include | |
| excludePaths | No | Patterns of files to exclude | |
| maxIssues | No | Maximum number of issues to report | |
| minSeverity | No | Minimum severity level to report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | URL of the repository to analyze (e.g., 'https://github.com/username/repo') | |
| depth | No | Analysis depth - higher values analyze more deeply but take longer (1-5) | |
| includeDependencies | No | Include dependency analysis in the results | |
| includeComplexity | No | Include complexity metrics in the results | |
| specificFiles | No | Specific files to analyze, can include glob patterns (e.g., ['src/*.ts', 'lib/utils.js']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | ||
| depth | No | ||
| includeExternalDependencies | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | No | URL of the repository to analyze (e.g., 'https://github.com/username/repo') | |
| filePath | No | Path to the file within the repository (e.g., 'src/main.ts') | |
| fileContent | No | Source code content to analyze directly instead of from a repository | |
| language | No | Programming language of the code (e.g., 'javascript', 'python', 'typescript', 'rust') | |
| metrics | No | Specific metrics to calculate, such as 'complexity', 'linesOfCode', 'maintainability', 'functions', 'classes' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the session to clear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Optional description for this session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| primaryRepoUrl | Yes | ||
| relatedRepoUrls | Yes | ||
| analysisType | No | dependencies | |
| contextDepth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | ||
| targetGoal | Yes | ||
| timeframe | Yes | ||
| includeImplementationDetails | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | ||
| format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Relative path to the directory | . |
| depth | No | Depth of folders to show |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Relative path to the file | |
| startLine | No | Starting line number (1-based) | |
| endLine | No | Ending line number (1-based) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the session to retrieve history for | |
| limit | No | Maximum number of history entries to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the session to retrieve information for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| repositoryUrl | No | ||
| contextDepth | No | ||
| includeExternalKnowledge | No | ||
| outputFormat | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | ||
| insightTypes | No | ||
| tags | No | ||
| relatedFile | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find code in the repository | |
| filePattern | No | Optional file pattern to limit search (e.g., '*.ts') | |
| maxResults | No | Maximum number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | ||
| includeContributorPatterns | No | ||
| includeTeamDynamics | No | ||
| timeRange | No | ||
| visualizationFormat | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | Yes | ||
| insightType | Yes | ||
| insightContent | Yes | ||
| relatedFiles | No | ||
| tags | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| insightId | Yes | ||
| insightContent | No | ||
| insightType | No | ||
| relatedFiles | No | ||
| tags | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | No | ||
| filePath | No | ||
| fileContent | No | ||
| showMethods | No | ||
| showAttributes | No | ||
| format | No | mermaid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryUrl | No | ||
| filePath | No | ||
| path | No | ||
| fileContent | No | ||
| format | No | mermaid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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-cursoranalyze-dependenciesanalyze-filesanalyze-metricsanalyze-qualityanalyze-repositorybuild-knowledge-graphcalculate-metricsclear-sessioncreate-sessioncross-repo-analysisevolution-pathwayexport-knowledge-graphfolder-structureget-fileget-session-historyget-session-infolist-quality-ruleslist-sessionsproject-infoquery-knowledge-graphretrieve-codebase-insightssearch-codesocio-technical-analysisstore-codebase-insightupdate-codebase-insightvisualize-code-structurevisualize-dependenciesMultiple tools have unclear boundaries and overlapping purposes, such as analyze-files, analyze-repository, and project-info, which could all relate to codebase analysis, and analyze-metrics versus calculate-metrics, which seem redundant. The lack of descriptions exacerbates this ambiguity, making it difficult for an agent to distinguish between similar-sounding tools like visualize-code-structure and visualize-dependencies.
The naming shows mixed conventions: most tools use kebab-case (e.g., analyze-cursor, build-knowledge-graph), but some deviate with underscores (e.g., cross-repo-analysis, socio-technical-analysis) or inconsistent verb styles (e.g., analyze-* versus get-* versus list-*). While readable, the patterns are not fully consistent, leading to a moderate score.
With 28 tools, this server feels heavy and potentially over-scoped for code analysis, suggesting redundancy or fragmentation. A typical well-scoped server might have 3-15 tools; this count is borderline excessive, indicating a lack of focus that could overwhelm agents and reduce usability.
Inferring the domain as code analysis, the tool set covers aspects like analysis, metrics, knowledge graphs, and visualization, but there are notable gaps. For example, it lacks clear CRUD operations for core entities beyond insights (e.g., no update or delete for sessions), and the overlap in analysis tools suggests incomplete coverage rather than a streamlined workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xjcf/MCP_CodeAnalysis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
