Características • Inicio rápido • Integración • Uso • Documentación • Contribuir • Licencia
Un servidor Model Context Protocol (MCP) listo para producción para aplicaciones Symfony. Proporciona a los asistentes de IA una introspección profunda y de solo lectura de todo tu código Symfony: rutas, controladores, servicios, entidades, esquema de base de datos, migraciones, eventos, formularios, seguridad, Doctrine, Messenger, Twig, API Platform y mucho más.
Cliente | Instalación |
Claude Code | Ejecuta |
Claude Desktop | Añade a |
Cursor | Añade a |
VS Code Copilot | Añade a |
Cualquier cliente MCP | transporte stdio, |
Available tool categories (16 categories, 1,679 tools total, ~164,729 tokens if all active)
Category │ Tools │ Est. tokens │ Description
─────────────────┼────────────┼────────────────┼────────────────────────────────────────────────────────
symfony-core │ 549 tools │ ~ 53995 tokens │ Routes, services, controllers, events, commands, bundles, DI container, kernel
database │ 176 tools │ ~ 17121 tokens │ Entities, migrations, Doctrine ORM, relationships, query patterns, indexes, DBAL
security │ 133 tools │ ~ 13008 tokens │ Voters, firewalls, authenticators, JWT, OAuth, CSRF, access control, secrets vault
frontend │ 121 tools │ ~ 11568 tokens │ Twig, translations, asset mapper, Symfony UX, Turbo, live components, Webpack
testing │ 110 tools │ ~ 10559 tokens │ PHPUnit, Behat, Cypress, Playwright, Psalm, PHPStan, Rector, static analysis
integrations │ 106 tools │ ~ 10939 tokens │ Stripe, Slack, Sentry, Elasticsearch, Twilio, SendGrid, Mailgun, Datadog, OpenAI
serializer │ 91 tools │ ~ 9031 tokens │ Serializer, validation, forms, constraints, DTOs, transformers, normalizers
messaging │ 87 tools │ ~ 8455 tokens │ Messenger, notifier, webhooks, Mercure, mailer, transports, stamps, failure handling
api │ 68 tools │ ~ 6438 tokens │ API Platform, OpenAPI, GraphQL, REST patterns, versioning, rate limits, Nelmio
infrastructure │ 68 tools │ ~ 6794 tokens │ Docker, CI/CD, Kubernetes, Terraform, Helm, Nginx, serverless, cloud platforms
cache-sessions │ 62 tools │ ~ 5945 tokens │ Cache pools, HTTP cache, sessions, rate limiter, lock, cache warmers, OPcache
config │ 35 tools │ ~ 3157 tokens │ Environment config, framework settings, Monolog, CORS, locale, feature flags
code-quality │ 25 tools │ ~ 2447 tokens │ Profiler, dead code detection, dependency graph, accessibility, code metrics
cloud-aws │ 18 tools │ ~ 1945 tokens │ AWS S3, SES, Cognito, ECS, Lambda/Bref, Parameter Store, Secrets Manager, CloudFront
cloud-other │ 16 tools │ ~ 1851 tokens │ Azure Blob/Pipelines, Google Cloud Run/Storage, Firebase, DigitalOcean, Consul
queues │ 14 tools │ ~ 1476 tokens │ RabbitMQ, Kafka, SQS FIFO/DLQ, Pusher, Redis pub/sub and streams
To activate a category: call activate_category(category: "<key>")
To search for specific tools: call search_tools(query: "what you want to do")Solo lectura — nunca escribe, modifica ni ejecuta nada
Redacción automática — las contraseñas, tokens, claves API y credenciales de base de datos se reemplazan con [REDACTED] antes de que cualquier dato llegue a la IA
Canalización DLP — escáner de prevención de pérdida de datos multicapa (patrones regex + detección estructural de tarjetas de crédito, JWT, claves SSH, credenciales de nube, etc.)
Validación de rutas — los ataques de traversal de directorios se bloquean en la capa de entrada
Sin ejecución de código — los archivos PHP se analizan estáticamente (sin eval, sin runtime de PHP)
Sin llamadas de red — todos los datos provienen solo de archivos locales
Filtro de inyección de prompts — la salida de las herramientas se escanea en busca de patrones de inyección antes de enviarse a la IA
Related MCP server: phpustik MCP Server
npx @shakaran/symfony-agent-mcpnpm install -g @shakaran/symfony-agent-mcp
symfony-agent-mcpgit clone https://github.com/shakaran/symfony-agent-mcp
cd symfony-agent-mcp
pnpm install
pnpm build
pnpm startConsulta GETTING_STARTED.md para una guía paso a paso que incluye configuración de Node.js, solución de problemas y verificación del primer uso.
Cliente | Instalación |
Cursor |
|
VS Code | |
VS Code Insiders | |
Windsurf | |
Claude Code | |
Claude Desktop |
Ejecuta una vez para registrar el servidor:
# npx (no local install required)
claude mcp add symfony -- npx @shakaran/symfony-agent-mcp
# Or from a local source build
claude mcp add symfony -- node /path/to/symfony-agent-mcp/dist/server.jsPara que esté disponible globalmente en todos los proyectos, añade la bandera --scope user:
claude mcp add --scope user symfony -- npx @shakaran/symfony-agent-mcpAñade a tu archivo de configuración de Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"symfony": {
"command": "npx",
"args": ["@shakaran/symfony-agent-mcp"]
}
}
}Añade a .cursor/mcp.json:
{
"symfony": {
"command": "npx",
"args": ["@shakaran/symfony-agent-mcp"]
}
}Añade a .vscode/mcp.json:
{
"servers": {
"symfony": {
"type": "stdio",
"command": "npx",
"args": ["@shakaran/symfony-agent-mcp"]
}
}
}Cada herramienta acepta un parámetro app_path que apunta a la raíz de tu aplicación Symfony:
list_routes(app_path: "/var/www/myapp")
→ Found 42 routes: GET /api/users [api_users], POST /login [app_login], …
get_entity_details(app_path: "/var/www/myapp", entity_name: "User")
→ Entity: User | Table: users
Properties: id (int, PK), email (string 180), isActive (bool)
Relationships: OneToMany → Post (author)
get_error_summary(app_path: "/var/www/myapp")
→ Last 24h: 3 CRITICAL, 12 ERROR, 47 WARNING
get_code_quality_report(app_path: "/var/www/myapp")
→ God classes: UserManager (1240 lines), dead services: 4, N+1 risks: 7Ejemplos de prompts que puedes usar con Claude:
"Muéstrame todas las rutas con métodos POST y sus controladores"
"¿Qué servicios están etiquetados con doctrine.event_listener?"
"Lista las últimas 50 líneas del registro de producción"
"¿Hay dependencias circulares en el contenedor de servicios?"
"¿Qué entidades de Doctrine tienen relaciones con User?"
"Muéstrame el historial de migraciones y cualquier migración destructiva"
"¿Qué controladores no tienen atributos de seguridad?"
Toda la configuración se realiza mediante variables de entorno pasadas al proceso del servidor MCP.
Variable | Por defecto | Descripción |
|
| Habilita el descubrimiento dinámico de herramientas. Cuando es |
|
| Máximo de tokens estimados que se pueden activar por sesión. La activación se bloquea cuando se excedería este límite; pasa |
Variable | Por defecto | Descripción |
| (cualquiera) | Lista separada por dos puntos de rutas absolutas de aplicaciones que el servidor puede inspeccionar. Ejemplo: |
|
| Establece a |
| (todas) | Lista blanca separada por comas de nombres de herramientas. Solo las herramientas listadas son invocables. |
| (ninguna) | Lista negra separada por comas. Tiene prioridad sobre la lista blanca. |
| (desactivado) | Secreto de 32+ caracteres para la firma de solicitudes. Habilita la autenticación por solicitud. |
| (desactivado) | Secreto para la generación de tokens de sesión. |
| (desactivado) | Token para validar en las solicitudes entrantes. |
|
| Establece a |
|
| Ventana de validez del token de sesión en segundos. |
Variable | Por defecto | Descripción |
|
| Máximo de solicitudes por ventana. Establece a |
|
| Ventana de límite de velocidad en milisegundos (1 minuto). |
|
| Máximo de solicitudes ráfaga en 1 segundo. |
Variable | Por defecto | Descripción |
| (desactivado) | Puerto para el transporte HTTP/SSE. Cuando se establece, inicia un servidor HTTP además de stdio. |
|
| Establece a |
|
| Tiempo de espera de ejecución por herramienta en milisegundos. |
{
"mcpServers": {
"symfony": {
"command": "npx",
"args": ["@shakaran/symfony-agent-mcp"],
"env": {
"SYMFONY_MCP_DYNAMIC_TOOLS": "false"
}
}
}
}{
"mcpServers": {
"symfony": {
"command": "node",
"args": ["/path/to/symfony-agent-mcp/dist/server.js"],
"env": {
"SYMFONY_MCP_TOKEN_BUDGET": "80000"
}
}
}
}Usa esto cuando quieras ejecutar el servidor desde un clon local (no se necesita publicación npm).
# 1. Clone the repo
git clone https://github.com/shakaran/symfony-agent-mcp
cd symfony-agent-mcp
# 2. Install dependencies (Node.js ≥ 22 required)
pnpm install # or: npm install
# 3. Build TypeScript → dist/
pnpm build # or: npm run build
# 4. Test the server responds
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | node dist/server.jsLuego configura tu cliente MCP para que apunte al archivo compilado:
Claude Code (ejecuta una vez):
claude mcp add symfony -- node /absolute/path/to/symfony-agent-mcp/dist/server.jsClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"symfony": {
"command": "node",
"args": ["/absolute/path/to/symfony-agent-mcp/dist/server.js"]
}
}
}VS Code (.vscode/mcp.json):
{
"servers": {
"symfony": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/symfony-agent-mcp/dist/server.js"]
}
}
}Consejo: Después de reconstruir (
pnpm build), reinicia tu cliente MCP para que tome los cambios.
El servidor lee archivos directamente de tu aplicación Symfony — no se necesita conexión a base de datos ni runtime de PHP:
config/routes.yaml, config/routes/*.yaml — Rutas YAML
Atributos PHP 8 #[Route] en los controladores de src/Controller/
config/services.yaml — Servicios del contenedor de DI
config/packages/*.yaml — Configuración de framework, security, doctrine, messenger y mailer
src/Entity/*.php — Archivos de entidad de Doctrine (atributos PHP 8 + anotaciones)
var/log/*.log — Registros de la aplicación
migrations/, src/Migrations/ — Archivos de migración de Doctrine
composer.json, composer.lock — Información del paquete
.env, .env.local, .env.*.local — Variables de entorno (los valores sensibles se redactan automáticamente)
Symfony | PHP | Mapeo ORM |
5.4 LTS | 8.0+ | Anotaciones o Atributos |
6.x | 8.0+ | Atributos |
7.x | 8.2+ | Atributos |
8.x | 8.2+ | Atributos |
Node.js ≥ 22.0.0
pnpm ≥ 11.0.0 (o npm/yarn para desarrollo)
pnpm install
pnpm dev # watch mode (TypeScript → dist/)
pnpm test # run all tests
pnpm lint # ESLint
pnpm typecheck # tsc --noEmitConsulta DEVELOPMENT.md para la guía de desarrollo completa: visión general de la arquitectura, adición de nuevas herramientas, estrategia de pruebas y pautas de contribución.
Documento | Descripción |
Configuración paso a paso, requisitos previos de Node.js, solución de problemas | |
Diseño del sistema, pipeline de seguridad, visión general de componentes, todas las 1.679 herramientas en 16 categorías documentadas | |
Flujo de trabajo de desarrollo, adición de herramientas, pruebas y contribución | |
Modelo de amenazas, pipeline DLP, política de divulgación responsable | |
Historial de versiones y hoja de ruta | |
Visión general del proyecto de alto nivel y estadísticas |
Las issues y las pull requests son bienvenidas en github.com/shakaran/symfony-agent-mcp.
Consulta DEVELOPMENT.md antes de enviar un PR, y SECURITY.md para conocer la política de divulgación responsable.
MIT © Ángel Guzmán Maeso
Activate all tools in a category for this session. After activation the MCP client will receive the full tool definitions on the next tools/list refresh. Use list_tool_categories to see available categories and their token costs. Pass force=true to override the token budget guard.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Override token budget warning and activate anyway (default false). | |
| category | Yes | Category key from list_tool_categories, e.g. "database", "api", "security". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the side effect (client receives full tool definitions on next refresh), the session scope, and the token budget guard behavior. It does not mention whether activation is reversible or if there are any side effects beyond the refresh, but the key behaviors are covered.
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?
Three sentences, each earning its place: the action and effect, the prerequisite listing tool, and the force parameter. Front-loaded with the primary action, no fluff.
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 (2 params, no output schema), the description is complete for an agent to call it correctly. It covers the action, the prerequisite, the parameter semantics, and the side effect. The only minor gap is not describing what happens after activation (e.g., whether tools are immediately available or require a refresh), but the description does mention the refresh behavior.
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 coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the purpose of force (override token budget warning) and the category format (key from list_tool_categories), which goes beyond the schema's basic descriptions. It doesn't add syntax details but the schema already provides those.
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 action ('Activate all tools in a category'), the resource ('category'), and the session scope. It distinguishes itself from siblings by mentioning the activation effect and the token budget guard, which is unique to this tool.
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 explicitly tells the agent to use list_tool_categories to see available categories and token costs, and explains the force parameter for overriding the budget guard. It implies when to use this tool (when you need tools from a category) and provides a clear alternative for listing categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a previously activated category from this session to free up context budget. Useful when switching between different areas of the codebase.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category key to deactivate, e.g. "database". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds useful behavioral context by noting the session scoping and the context-budget effect. However, it does not disclose behavior for edge cases like deactivating a category that is not active, or whether the operation is reversible.
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?
Two concise sentences with no filler. The primary action and its purpose are front-loaded, and the use-case guidance is directly relevant.
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 one-parameter, session-scoped tool, the description covers what it does, why it matters, and when to use it. It does not mention listing available categories, but the sibling tool list_tool_categories is available in context, making this 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?
Schema description coverage is 100%, and the schema already documents the 'category' parameter with an example. The description reinforces the meaning by referring to 'previously activated category' but adds no new parameter-level details beyond the schema.
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?
States a specific verb ('Remove'), a specific resource ('previously activated category'), and the scope ('from this session'). It clearly distinguishes the tool from its sibling activate_category by describing the inverse operation.
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?
Provides a clear use case: 'Useful when switching between different areas of the codebase.' It implies when to use the tool, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which tool categories are currently active in this session, how many tools are exposed, and the estimated token cost. Use this to understand your current context budget.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so behavioral disclosure falls entirely on the description. The word 'Show' communicates read-only introspection, and the description explicitly reveals that the tool returns session state, a count of exposed tools, and an estimated token cost. It does not explicitly say it has no side effects, but the verb and zero-parameter design make that clear enough.
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?
Two concise sentences with no filler. The first sentence front-loads exactly what the tool reports, and the second sentence explains why the agent would call it. Every word earns its place.
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 zero-parameter, no-output-schema tool, this description is fully adequate. It conveys the tool's scope, output, and a motivating use case. Nothing essential is missing for a model to invoke the tool appropriately.
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?
With zero parameters and 100% schema coverage, the schema is already complete and the description has no parameter details to add. The description does contribute some useful semantics by clarifying what the response will contain, namely active categories, count of exposed tools, and token cost.
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, 'Show', and names a clear resource: the tool categories that are currently active in this session, plus a count and estimated token cost. The phrase 'currently active' and the context-budget emphasis clearly set it apart from sibling tools like list_tool_categories or search_tools.
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 directly tells the agent when to use the tool: 'Use this to understand your current context budget.' It clearly establishes a use case, though it does not explicitly mention exclusions alternatives such as when the agent should use list_tool_categories instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available tool categories with descriptions, tool counts, and estimated token cost. Use this first to understand what groups of tools exist before activating them. Only the categories you activate will be shown in subsequent tools/list calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers the crucial state-dependent behavior: 'Only the categories you activate will be shown in subsequent tools/list calls.' This is exactly the kind of non-obvious behavior an agent must know. It could also state that this call is side-effect-free, but the provided disclosure is strong.
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?
Three sentences, zero waste, with the most important information front-loaded. Each sentence serves a distinct purpose: what it lists, when to call it, and a critical behavioral caveat. This is a model of concise, useful 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?
For a zero-parameter list tool with no output schema, this description is complete. It covers return contents, invocation order, and a behavioral subtlety that would otherwise be invisible. An agent has everything it needs to decide when and how to call this 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?
There are 0 parameters and schema coverage is 100%, so the baseline is already a 4. The description doesn't need to add parameter semantics since there are none, and it doesn't waste words trying.
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?
States a specific verb ('List'), a clear resource ('all available tool categories'), and the exact fields returned (descriptions, tool counts, token cost). The distinction from siblings is mostly implied via the workflow cue 'before activating them,' but it doesn't name an alternative sibling like the calibration gold standard, so it falls just short of a 5.
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?
Gives explicit guidance to 'Use this first' before activating categories, which clearly signals the intended position in the workflow. It doesn't explicitly discuss when not to use this tool or contrast with search_tools, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific tools by describing what you want to do. Returns the top matching tool definitions (name + description + input schema) ready to call immediately — no activation needed for one-off use. For repeated use of a group, call activate_category instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 8, max 20). | |
| query | Yes | Natural language description of what you want to do, e.g. "detect N+1 queries" or "list Symfony routes". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the return shape (name + description + input schema), the relevance model ('top matching'), and the key behavior that no activation is needed. This is solid coverage for a read-only search tool, though it does not mention edge cases like no matches found.
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 compact and front-loaded: the search intent is in the first sentence, return behavior in the second, and the alternative activation path in the third. There is no redundant text or unnecessary detail.
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 two-parameter search tool with no output schema, the description gives the agent enough to know what to pass, what it will receive, and whether activation is required. It also mentions the key distinction from activate_category, making the tool self-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%, so the input schema already documents both query and limit. The description adds no additional parameter-level meaning beyond what the schema provides, 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 states a specific verb ('Search') and resource ('specific tools') and explains how the search is expressed: by describing what you want to do. It also mentions that it returns ready-to-call tool definitions, which clearly separates it from the category-oriented sibling tools.
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 gives explicit routing for one-off use versus repeated use ('For repeated use of a group, call activate_category instead'). It implies when search_tools is appropriate rather than listing a category, but it does not explicitly contrast with list_tool_categories or get_active_tools.
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.
v1.0.1activate_categorydeactivate_categoryget_active_toolslist_tool_categoriessearch_toolsScored across 5 tools
Each tool has a clearly distinct purpose: listing categories, searching tools, activating a category, viewing active categories, and deactivating. There is no overlap or ambiguity in their functions.
All tool names follow a consistent verb_noun snake_case pattern (list_tool_categories, search_tools, activate_category, get_active_tools, deactivate_category), making prediction and selection straightforward.
With 5 tools, the set is tightly scoped to the server's purpose of managing tool categories and sessions. Each tool serves a necessary role in the lifecycle without redundancy or bloat.
The surface covers the full lifecycle of tool category management: discovery (list/search), activation, status inquiry, and deactivation. No obvious gaps exist for the stated domain.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
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.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
