Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cybersecurity Professor MCP Server Explain how a buffer overflow works"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Prof. Null — Tu profesor de ciberseguridad impulsado por Claude AI, sin censuras, de cero a experto.
Un servidor MCP (Model Context Protocol) que expone a Prof. Null como un conjunto de herramientas especializadas que cualquier cliente MCP compatible (Claude Desktop, Cursor, etc.) puede usar para aprender ciberseguridad con profundidad técnica real.
Related MCP server: HackBridge
Herramienta | Descripción |
| Pregunta libre al Prof. Null — cualquier tema, sin filtros |
| Ruta de aprendizaje personalizada según tu nivel y objetivos |
| Cheatsheet completo de cualquier herramienta de hacking |
| Explicación técnica profunda de ataques, CVEs y vulnerabilidades |
| Laboratorio práctico paso a paso para cualquier técnica |
| Pistas progresivas para CTF challenges (sin spoilers, o con ellos) |
| Catálogo de herramientas por categoría con comparativas |
| Análisis técnico de CVEs: mecanismo, exploit, mitigación |
| Comprueba si el servidor está activo y muestra su configuración básica. |
| Describe brevemente una herramienta MCP disponible en este servidor. |
Node.js 18+
API key de Anthropic
# 1. Clonar o descomprimir el servidor
cd cybersec-mcp
# 2. Instalar dependencias
npm install
# 3. Configurar tu API key de Anthropic
export ANTHROPIC_API_KEY="sk-ant-..."
# O en Windows: set ANTHROPIC_API_KEY=sk-ant-...
# 4. Probar que funciona
node src/index.js
# Deberías ver: 🛡️ Cybersecurity Professor MCP Server running
# 5. Ejecutar tests
npm testEdita ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) o %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"cybersecurity-professor": {
"command": "node",
"args": ["/ruta/absoluta/a/cybersec-mcp/src/index.js"],
"env": {
"ANTHROPIC_API_KEY": "sk-ant-tu-api-key-aqui"
}
}
}
}En .cursor/mcp.json:
{
"mcpServers": {
"cybersecurity-professor": {
"command": "node",
"args": ["/ruta/absoluta/a/cybersec-mcp/src/index.js"],
"env": {
"ANTHROPIC_API_KEY": "sk-ant-tu-api-key-aqui"
}
}
}
}{
"mcpServers": {
"cybersecurity-professor": {
"command": "npx",
"args": ["cybersec-mcp"],
"env": {
"ANTHROPIC_API_KEY": "sk-ant-tu-api-key-aqui"
}
}
}
}"Prof. Null, explícame cómo funciona un Pass-the-Hash attack en Active Directory"
"Quiero una ruta para convertirme en red teamer, tengo nivel intermedio y 2 horas al día"
"Dame el cheatsheet completo de BloodHound con técnicas de AD enumeration"
"Genera un laboratorio para practicar Kerberoasting desde cero"
"Explícame Log4Shell (CVE-2021-44228) con exploit incluido"
"Estoy en un CTF de pwn, hay un buffer overflow pero no sé por dónde empezar"
cybersec-mcp/
├── src/
│ ├── index.js # MCP Server principal + definición de todas las herramientas
│ ├── professor.js # System prompt de Prof. Null
│ └── data/
│ ├── tools.js # Base de datos de herramientas de referencia
│ └── roadmap.js # Datos de certificaciones y rutas
├── package.json
└── README.mdVariable | Requerida | Descripción |
| ✅ Sí | Tu API key de Anthropic (console.anthropic.com) |
| ❌ No | URL base de API de Anthropic (por defecto: https://api.anthropic.com) |
| ❌ No | Modelo Claude a usar. Default: |
| ❌ No | Tope de tokens por llamada. Default: |
| ❌ No | Timeout de llamada en ms. Default: |
| ❌ No | Reintentos ante errores transitorios. Default: |
| ❌ No | Nombre del servidor MCP expuesto. Default: |
| ❌ No | Versión del MCP. Default: |
| ❌ No | Nivel de logs: |
| ❌ No | Entorno de ejecución: |
Este servidor está diseñado para educación, investigación y pentesting autorizado. Prof. Null proporciona información técnica completa sobre seguridad ofensiva bajo el principio de que:
El conocimiento defensivo requiere comprender el ataque
Los profesionales de seguridad necesitan formación sin filtros artificiales
La ética se enseña en contexto, no mediante restricciones técnicas
Úsalo responsablemente: solo en sistemas donde tengas autorización explícita.
MIT — Úsalo, modifícalo, mejóralo.
Pregunta cualquier cosa al Prof. Null sobre ciberseguridad, hacking, pentesting, herramientas, conceptos, técnicas o carrera. El profesor responde sin censuras con profundidad técnica real.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Tu nivel actual (opcional — el profesor lo detecta solo) | |
| language | No | Idioma de respuesta (default: español) | es |
| question | Yes | Tu pregunta sobre ciberseguridad (cualquier nivel, sin filtros) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions 'responde sin censuras con profundidad técnica real', which reveals the uncensored and technically deep nature. However, it doesn't disclose any limitations, safety disclaimers, or what happens if the question is out of scope, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that front-loads the purpose and adds value with 'sin censuras' and 'profundidad técnica real'. No wasted words; every phrase contributes to understanding.
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 Q&A tool with well-documented parameters and no output schema, the description is mostly complete. It covers the range of topics and the response style. However, it omits any context about educational intent or potential misuse, which might be expected given the uncensored security nature, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (question, level, language) are already well documented. The description adds no additional meaning beyond the schema, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: asking anything about cybersecurity, hacking, pentesting, tools, concepts, techniques, or career. It uses a specific verb ('Pregunta') and resource (Prof. Null), and differentiates from siblings by being a general Q&A tool rather than a narrow utility like explain_attack or ctf_hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies general usage ('Pregunta cualquier cosa') but provides no explicit guidance on when to prefer this tool over siblings or when not to use it. There are no references to alternative tools for specific tasks like getting roadmaps or cheatsheets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtén pistas progresivas para resolver challenges de CTF sin spoilers directos. El profesor te guía sin darte la solución completa... a menos que lo pidas.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Categoría del CTF challenge | |
| platform | No | Plataforma del CTF (HackTheBox, TryHackMe, PicoCTF, etc.) | |
| hint_level | No | Qué tan directa quieres la ayuda | pista-suave |
| what_tried | No | Qué has intentado ya (para no repetir pistas) | |
| challenge_description | Yes | Descripción del challenge o lo que ves/sabes hasta ahora |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: progressive hints, no direct spoilers, and ability to get full solution on request ('a menos que lo pidas'). This adds meaningful context about how the tool behaves, though it doesn't cover all edge cases.
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 sentences, front-loaded with the main purpose, and no unnecessary detail. 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?
Given the tool's simplicity and full schema coverage, the description adequately covers purpose and behavior. It could benefit from mentioning the hint_level parameter, but the schema already covers that. Overall complete enough.
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% with all parameters described. The description doesn't add significant detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides progressive hints for CTF challenges without direct spoilers, using the verb 'obtén' and specific resource 'pistas progresivas'. It distinguishes from siblings like ask_professor by focusing on hints rather than general Q&A.
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 usage context is implied: use when stuck on a CTF challenge and want guided hints. However, it does not explicitly mention when to use this tool versus alternatives like ask_professor or get_cheatsheet, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe brevemente una herramienta MCP disponible en este servidor.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | Nombre de la herramienta MCP a describir |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'describe', which implies a read-only, non-destructive operation, but does not explicitly mention side effects, permissions, or output characteristics. Minimal context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded and free of any extraneous information. Every word serves a purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is somewhat adequate. However, it does not specify what the returned description contains (e.g., parameters, usage examples), leaving some ambiguity for the agent. It meets the minimum viable threshold but lacks richness.
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?
Parameter schema coverage is 100%, so the schema fully explains the only parameter 'tool_name'. The tool description adds no extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'describe' and the resource 'an MCP tool available on this server', making it easy to understand the basic function. It does not explicitly differentiate from sibling tools like list_tools, but the tool name and wording are specific enough to convey the purpose.
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?
No guidance is given on when to use this tool compared to alternatives such as list_tools or other query tools. The description only states what the tool does, implying usage but not providing explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicación técnica profunda de cualquier ataque, vulnerabilidad, técnica ofensiva o CVE. Incluye mecanismo interno, PoC, detección y mitigación.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Profundidad: conceptual=cómo funciona, tecnico=con código/comandos, exploit-dev=nivel bajo con asm/memoria | tecnico |
| attack | Yes | Nombre del ataque, vulnerabilidad o técnica (ej: kerberoasting, sql injection, buffer overflow, CVE-2021-44228, pass-the-hash, SSRF, etc.) | |
| include_poc | No | Incluir Proof of Concept funcional con código real | |
| include_defense | No | Incluir detección y mitigación defensiva |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the output includes internal mechanism, PoC, detection, and mitigation, which is useful, but it does not mention operational behaviors like whether it executes code, output format, or auth requirements. A plain text-generation tool was not explicitly ruled out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Spanish that front-loads the purpose and immediately lists the key contents. Every word earns its place; no redundant or vague filler is present.
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 text-generation tool with no output schema, the description adequately defines the output components (mechanism, PoC, detection, mitigation) and the parameter schema fills in the rest. It could have clarified the output format or length, but that is not essential for an AI agent to use it correctly.
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 baseline is 3. The description adds no extra parameter information beyond what the schema already provides, but the schema itself thoroughly documents each parameter (attack, depth, include_poc, include_defense) with descriptions and defaults.
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 ('Explicación técnica profunda') and clearly names the resource categories (ataque, vulnerabilidad, técnica ofensiva, CVE). It lists concrete deliverables (mecanismo interno, PoC, detección y mitigación), which distinguishes it from sibling tools like search_cve or get_cheatsheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it covers any attack/vulnerability/technique/CVE and includes PoC, detection, and mitigation. However, it does not explicitly mention when not to use it or point to alternative sibling tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera un laboratorio práctico completo y paso a paso para practicar cualquier técnica de ciberseguridad en un entorno controlado.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Tema del laboratorio (ej: 'SQL injection manual', 'Active Directory attacks', 'Buffer overflow básico', 'Configurar lab de red team') | |
| duration | No | Tiempo disponible para el laboratorio | 2h |
| environment | No | Ambiente preferido para el laboratorio | local-vm |
| os_attacker | No | OS del atacante | kali |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it generates a lab, which is a non-destructive content generation behavior, but it does not disclose any limitations, prerequisites, or what the output format will be. For a simple generator, this is sufficient but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the main action and quickly conveys the tool's purpose. It is appropriately sized with no redundant information.
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 (4 params, all documented) and lack of output schema, the description covers the core purpose but does not elaborate on the generated lab's structure or how to interpret the output. Since no output schema exists, the description could benefit from mentioning what the output contains, but it is adequate for basic selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptive text for all four parameters (topic, duration, environment, os_attacker), achieving 100% coverage. The description itself adds no additional parameter semantics beyond restating the general purpose; it does not explain how parameters interact or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a complete, step-by-step practical lab for practicing any cybersecurity technique, using the specific verb 'Genera' and resource 'laboratorio práctico completo y paso a paso'. This distinguishes it from sibling tools like get_cheatsheet or get_roadmap, which provide reference materials rather than hands-on labs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to practice a technique in a controlled environment, but it does not explicitly compare with alternatives or state when not to use it. There is no mention of when to choose generate_lab over explain_attack or ctf_hint, making usage guidance only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtén un cheatsheet completo y actualizado de cualquier herramienta de hacking/seguridad con ejemplos reales de uso en pentesting.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Contexto de uso para filtrar los comandos más relevantes | general |
| tool_name | Yes | Nombre de la herramienta (ej: nmap, burpsuite, metasploit, hashcat, sqlmap, ffuf, nuclei, crackmapexec, bloodhound, impacket, etc.) | |
| include_evasion | No | Incluir técnicas de evasión de detección para la herramienta |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'get' implies a read-only retrieval, and the description mentions 'complete and updated', which hints at potential dynamic content. However, it does not disclose any side effects, output format, or external dependencies. Still, for a simple cheatsheet tool, the description is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core purpose. Every word contributes to defining the tool's function. No unnecessary details or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a well-structured schema and no output schema. The description adequately explains what the cheatsheet contains (real usage examples) and its scope (any hacking/security tool). While it doesn't detail return format, this is not critical given the tool's simplicity and schema quality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all three parameters (tool_name, context, include_evasion) well documented in the schema. The description adds little beyond the schema, only reinforcing that tool_name can be any tool. Baseline 3 is appropriate as the schema does the heavy lifting.
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 that the tool provides a complete and updated cheatsheet for any hacking/security tool with real pentesting examples. It uses a specific verb ('Obtén') and resource ('cheatsheet de herramienta de hacking/seguridad'). However, it does not explicitly differentiate from sibling tools like 'describe_tool', which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs a cheatsheet with practical examples, but it does not provide explicit guidance on when to use this tool versus alternatives like 'describe_tool' or 'ask_professor'. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera una ruta de aprendizaje personalizada de ciberseguridad basada en tu nivel actual, objetivos y tiempo disponible.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Tu objetivo o especialización deseada | |
| budget | No | Presupuesto para cursos/labs/certs (cero=solo gratis) | bajo |
| current_level | Yes | Tu nivel actual de conocimiento | |
| time_available | Yes | Tiempo diario disponible para estudiar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No se proveen anotaciones, por lo que la descripción carga con toda la responsabilidad de transparencia. Solo repite el propósito sin detallar si hay efectos secundarios, requisitos de autenticación, formato de salida o limitaciones. No agrega contexto conductual más allá de lo evidente.
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?
La descripción es una sola frase clara, directa y sin información redundante. La acción principal y los insumos clave están al frente, cumpliendo con los requisitos de concisión y estructura.
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?
La descripción es suficiente para entender la función básica, pero al no haber output schema ni anotaciones, carece de detalles sobre el formato o alcance de la ruta generada. Tampoco menciona el parámetro opcional 'budget', aunque esto está cubierto por el schema.
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?
El input schema tiene cobertura del 100% con descripciones y enums para todos los parámetros, por lo que la descripción no necesita compensar. Aunque la descripción menciona nivel, objetivo y tiempo, no aporta semántica adicional que no esté ya en el 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?
La descripción usa el verbo específico 'Genera' y el recurso 'ruta de aprendizaje personalizada de ciberseguridad', diferenciándola claramente de hermanas como get_cheatsheet o explain_attack. Además menciona los criterios de personalización (nivel, objetivos, tiempo), lo que deja clara su función.
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?
La descripción implica que debe usarse cuando se desea una ruta de estudio personalizada, pero no ofrece alternativas explícitas ni condiciones de cuándo no usarla frente a get_cheatsheet o ask_professor. No hay guía de uso contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprueba si el servidor MCP está activo y qué configuración básica está cargada.
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It indicates a read-only check (server active and config loaded) but does not mention side effects (likely none), required permissions, error behavior, or return format details. The description is adequate but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary action and resource. Every word contributes meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description explains the core purpose and indicates that configuration details are returned, but it does not elaborate on the 'verbose' parameter or the exact structure of the response. This is a minor gap for a health check tool, leaving it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'verbose' is not explained in the description, and schema description coverage is 0%. The schema provides type and default, but the description does not clarify what 'verbose' does or how it affects the output. Since there is no description compensation for the low schema coverage, the semantics are incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Comprueba' / checks) and distinct resource ('el servidor MCP está activo y qué configuración básica está cargada'). It differentiates itself from sibling tools by focusing on server health and configuration checks rather than content or lab-related actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear context for use: when you need to verify server status or basic configuration. It does not explicitly mention when not to use it or suggest alternatives, but the utility is self-evident among the sibling tools, and no competing tool covers health checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista herramientas de ciberseguridad organizadas por categoría, con descripción y casos de uso.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Categoría de herramientas a listar | todas |
| include_alternatives | No | Incluir alternativas y comparativas entre herramientas similares |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It explains that the tool returns a categorized list of tools with descriptions and use cases, which implies a read-only operation, but it does not disclose response structure, pagination, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and output content without redundant or extraneous wording. Every part contributes meaning.
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 read/list tool, the description is adequate: it states what is returned and the schema documents both parameters. While there is no output schema or annotations, the tool's behavior is low-risk and the description covers the essential return values ('descripción y casos de uso').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage for all parameters, including descriptions, enums, and defaults. The description does not add any parameter-specific meaning beyond what is already in the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista herramientas') and resource ('de ciberseguridad'), with additional context on organization by category and inclusion of descriptions and use cases. It is not a tautology, but it does not explicitly differentiate from sibling tools like describe_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?
No guidance is provided about when to use this tool versus alternatives such as describe_tool, get_cheatsheet, or explain_attack. The only implied usage is for listing tools by category, but there are no explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explica cualquier CVE o vulnerabilidad conocida: cómo funciona técnicamente, si hay exploit público, cómo detectarla y parchearla.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_or_vuln | Yes | CVE ID (ej: CVE-2021-44228) o nombre de vulnerabilidad (ej: Log4Shell, EternalBlue, PrintNightmare) | |
| include_exploit | No | Incluir análisis del exploit disponible y cómo funciona | |
| affected_systems | No | Sistema específico que quieres verificar (ej: Apache 2.4.49 en Ubuntu 20.04) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool will explain technical functioning, public exploits, detection, and patching, providing good transparency about expected behavior. It doesn't mention any limitations or side effects, but for an informational tool this is adequate.
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?
Single sentence, front-loaded with the action, and lists key aspects without redundancy. Excellent structure.
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 tool with 3 params and no output schema, the description adequately covers the purpose, scope, and expected content. It could mention behavior on not found, but it's 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?
The schema descriptions cover 100% of parameters, so the baseline is 3. The description doesn't add specific parameter semantics beyond the schema, but it reinforces the primary parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explains CVEs/vulnerabilities, specifying technical details, public exploit, detection, and patching. This specific verb+resource+scope distinguishes it from siblings like explain_attack.
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 clearly indicates when to use the tool: when you need to understand a CVE or vulnerability, including technical workings, exploit, detection, and patching. It doesn't explicitly mention alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes (Q&A, roadmaps, cheatsheets, labs, CTF hints, server info). However, explain_attack and search_cve both cover vulnerabilities/CVEs with similar depth, and ask_professor can also answer such questions, creating some ambiguity.
Nearly all tools follow a verb_noun snake_case pattern (ask_professor, get_roadmap, explain_attack). Minor exceptions like ctf_hint and health_check deviate from the verb-first style, but the overall naming is consistent and predictable.
At 10 tools, the server is well-scoped for a cybersecurity professor: educational resources, technical explanations, lab generation, CTF assistance, and server utilities. No redundancy or bloat.
The tool surface covers learning paths, reference, attack/CVE explanations, hands-on labs, CTF support, and server introspection. No obvious gaps for the stated purpose; ask_professor fills any residual needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server for deep research or task groups
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yesidleon1393/cybersec-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
