Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-toolkit-server Check SSL certificate for example.com"
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.
Convertí a Claude en tu asistente de ciberseguridad. Este servidor MCP expone 17 herramientas de red, criptografía y análisis de seguridad directamente en tus conversaciones con Claude Desktop o Claude Code, sin salir del chat.
MCP (Model Context Protocol) es el estándar abierto de Anthropic para conectar modelos de IA con herramientas y fuentes de datos externas. Funciona como un "conector universal": en lugar de integrar cada herramienta a mano, un servidor MCP las expone todas a la vez para cualquier cliente compatible.
Lo que esto significa en la práctica: podés preguntarle a Claude "¿el certificado SSL de mi servidor vence esta semana?" o "analizá este JWT y decime si tiene vulnerabilidades" y Claude ejecuta las herramientas, interpreta los resultados y te da una respuesta contextualizada, todo dentro de la conversación.
Related MCP server: Tengu
Este proyecto nació como parte de una ruta de aprendizaje en ciberseguridad. El objetivo es doble:
Práctica real: implementar herramientas que se usan en auditorías, reconocimiento web y análisis de tokens, entendiendo cada detalle por dentro.
Productividad con IA: potenciar el flujo de trabajo cotidiano en seguridad integrando estas capacidades directamente con Claude.
Las herramientas no son wrappers de otras CLIs — están implementadas en Python puro usando la stdlib más dnspython, para entender exactamente qué pasa en cada operación.
Herramienta | Descripción |
| SO, versión, arquitectura, Python, hora UTC |
| Espacio total / usado / libre en GB |
| SHA-256 / SHA-1 / MD5 de un archivo — verificación de integridad |
| Lista archivos y carpetas con tipo |
Herramienta | Descripción |
| Validez, días hasta expiración, emisor, protocolo, cifrado, SANs |
| Auditoría de HSTS, CSP, X-Frame-Options, MIME, Referrer-Policy. Score /6 |
| HTTP client completo — probar APIs, analizar respuestas |
| Registros A, AAAA, MX, NS, TXT, CNAME |
| Registrante, fechas de creación/expiración, nameservers |
Herramienta | Descripción |
| ~35 puertos TCP en paralelo. Detecta servicios críticos expuestos (Docker, Redis, MongoDB, SMB...) con consejos de hardening |
| Análisis de entropía en bits, diversidad de charset, patrones débiles comunes |
Herramienta | Descripción |
| Contraseña segura con |
| API keys, secrets, session IDs en hex / base64 / urlsafe |
| Hash de strings — sha256, sha512, md5, blake2b, sha3_256 |
| Decodifica header + payload, detecta: expiración, |
| Codificación base64 standard o URL-safe |
| Decodificación base64 con autodetección de padding |
"¿El certificado SSL de api.miempresa.com está por vencer?"
→ verificar_certificado_ssl("api.miempresa.com")
Estado: ADVERTENCIA — expira en 12 días
Emisor: Let's Encrypt
SANs: api.miempresa.com, www.api.miempresa.com"Auditá los headers de seguridad de nuestro panel de admin"
→ verificar_headers_seguridad("https://admin.miempresa.com")
Score: 2/6 — Bajo
[OK] Strict-Transport-Security: max-age=31536000
[OK] X-Content-Type-Options: nosniff
[--] Content-Security-Policy
[--] X-Frame-Options ← ¡expuesto a clickjacking!
Fuga: Server: nginx/1.18.0 ← versión expuesta"Decodificá este JWT del login y decime si tiene algo raro"
→ analizar_jwt("eyJhbGci...")
Algoritmo: HS256
⚠ TOKEN EXPIRADO — venció el 2024-03-15 10:00 UTC
Claim 'role': admin
Claim 'sub': user_1337"Chequeá qué puertos tiene abiertos mi VPS en producción"
→ escanear_puertos("203.0.113.42")
22/tcp SSH
80/tcp HTTP
6379/tcp Redis ← CRÍTICO: Redis sin autenticación — activar requirepass
27017/tcp MongoDB ← CRÍTICO: expone toda la base de datos"Generame un API key para el nuevo microservicio"
→ generar_token_aleatorio(32, "hex")
a3f8c2e1d9b7045f6a2c8e4d1f0b3a9c7e2d5f8b1a4c7e0d3f6b9a2c5e8d1f4
Entropía: 256 bitsgit clone https://github.com/GonzaBot/mcp-toolkit-server.git
cd mcp-toolkit-server
pip install -e .Dependencias: mcp>=1.0.0, dnspython>=2.0.0. El resto es stdlib de Python 3.10+.
Editá el archivo de configuración de Claude Desktop:
SO | Ruta |
macOS |
|
Linux |
|
Windows |
|
{
"mcpServers": {
"mcp-toolkit-server": {
"command": "mcp-toolkit-server"
}
}
}Reiniciá Claude Desktop. Las 17 herramientas aparecen automáticamente disponibles en la conversación.
claude mcp add mcp-toolkit-server mcp-toolkit-serverO en modo proyecto, editá .claude/mcp.json:
{
"mcpServers": {
"mcp-toolkit-server": {
"command": "mcp-toolkit-server"
}
}
}mcp-toolkit-server/
├── src/mcp_toolkit_server/
│ ├── server.py # Punto de entrada — registra las 17 tools con FastMCP
│ └── tools/
│ ├── system.py # Info del SO y espacio en disco
│ ├── files.py # Hash de archivos y listado de directorios
│ ├── security.py # Escaneo de puertos y análisis de contraseñas
│ ├── network.py # SSL, headers HTTP, requests, DNS, WHOIS
│ └── crypto.py # Passwords, tokens, hashing, JWT, Base64
├── tests/
│ └── test_tools.py # 53 tests — 47 offline + 6 con internet
├── examples/
│ └── claude_desktop_config.json
└── pyproject.toml# Instalar dependencias de desarrollo
pip install -e ".[dev]"
# Tests offline (sin internet)
pytest -k "not network"
# Tests completos (incluye verificaciones contra google.com, httpbin.org)
pytest -m network
# Todo junto
pytest -v53 tests cubriendo: happy path, casos de error, valores criptográficos conocidos (hash SHA-256 de string vacío, MD5 de "hello"), JWTs expirados, algoritmo none, Base64 con y sin padding, tokens hex/base64/urlsafe.
Agregá la función al módulo correspondiente en tools/ (o creá uno nuevo).
Registrala en server.py con @mcp.tool().
Escribí un docstring claro — Claude lo usa para saber cuándo y cómo invocarla.
# tools/network.py
def mi_herramienta_nueva(parametro: str) -> str:
"""Descripción clara de qué hace y cuándo usarla.
Args:
parametro: qué representa
"""
return resultado
# server.py
@mcp.tool()
def mi_herramienta_nueva(parametro: str) -> str:
"""Descripción clara de qué hace y cuándo usarla.
Args:
parametro: qué representa
"""
return network.mi_herramienta_nueva(parametro)Las herramientas de reconocimiento de red (escanear_puertos, whois_dominio, consultar_dns, verificar_certificado_ssl) deben usarse únicamente sobre:
Sistemas propios
Sistemas sobre los que tenés autorización explícita del propietario
Escanear sistemas de terceros sin permiso puede ser ilegal según la jurisdicción.
Transporte HTTP/SSE para acceso remoto (correr el servidor en un VPS)
verificar_ip_reputacion — consultar AbuseIPDB / VirusTotal
auditar_dependencias — integrar pip-audit para detectar CVEs en proyectos Python
detectar_tecnologias — fingerprinting de stack tecnológico por headers y respuestas
GitHub Actions con tests en CI/CD
Tests de integración con cliente MCP simulado
MIT © Gonzalo D. Rodríguez de Mello
Decodifica y analiza un JWT (JSON Web Token) sin verificar la firma.
Muestra header, payload y todos los claims. Detecta: tokens expirados, algoritmo 'none' (vulnerabilidad crítica), algoritmos simétricos vs asimétricos, claims de seguridad (sub, iss, aud, roles, scope, permissions).
Args: token: JWT en formato header.payload.signature
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses critical behavior: no signature verification, detection of expired tokens and algorithm vulnerabilities. It does not mention read-only nature or side effects, but as a decode tool, it is safe. Adds useful context beyond the schema.
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 well-structured with a purpose sentence, a list of features, and an Args section. It is front-loaded with the main action. Could be slightly more concise, but every sentence adds value.
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 that an output schema exists (as per context), the description need not explain return values. It covers the parameter thoroughly and details what the tool shows and detects. No missing information for a JWT analysis 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?
Schema coverage is 0% (no parameter descriptions), so the description must compensate. It provides a clear description of the 'token' parameter: 'JWT in format header.payload.signature', adding meaning beyond the schema's type 'string'. This is helpful for correct invocation.
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 decodes and analyzes a JWT without verifying the signature, listing specific outputs (header, payload, claims) and detections (expired tokens, vulnerabilities). It is specific and distinguishes from any sibling tools (none are JWT-related).
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 for inspecting JWT content (decode and analyze) but does not explicitly state when to use or not use this tool versus alternatives. No exclusions or alternative tools are mentioned, leaving usage context implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula el hash (sha256, sha1, md5) de un archivo para verificar su integridad.
Args: ruta_archivo: ruta al archivo algoritmo: algoritmo de hash a usar (sha256, sha1, md5)
| Name | Required | Description | Default |
|---|---|---|---|
| algoritmo | No | sha256 | |
| ruta_archivo | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses basic behavior (hash calculation) but omits details like file existence requirements, permissions, size limits, or output format. The output schema exists but is not referenced.
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?
Description is concise with two sentences and an Args list. It is front-loaded with the main purpose. No unnecessary details.
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?
Adequate for a file hash tool with output schema present. However, it lacks details on error handling, execution context, and does not leverage the output schema to explain return values.
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 has 0% description coverage, so the description adds essential meaning: 'ruta_archivo' as path and 'algoritmo' with options. It clarifies purpose beyond schema titles but does not mention default value.
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 calculates hash (sha256, sha1, md5) of a file for integrity verification. It distinguishes from sibling 'calcular_hash_texto' by specifying files as input.
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 for file integrity verification but does not explicitly contrast with siblings or state when not to use. The context is clear, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula el hash de un texto arbitrario.
Útil para verificar integridad de datos, comparar valores o crear identificadores.
Args: texto: el texto a hashear algoritmo: sha256, sha512, sha1, md5, blake2b, sha3_256
| Name | Required | Description | Default |
|---|---|---|---|
| texto | Yes | ||
| algoritmo | No | sha256 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the computation type and algorithms but lacks details like output format (e.g., hex string), performance considerations, or handling of large inputs. Basic but 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?
Concise, front-loaded with purpose, followed by use cases and parameter details. Every sentence adds value without redundancy.
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 the existence of an output schema, the description is reasonably complete. It covers all parameters and usage context, though it omits output specification and potential errors.
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 0%, yet description fully explains both parameters: 'texto' as the text to hash and 'algoritmo' with a specific list of allowed algorithms (sha256, sha512, etc.). This adds critical meaning beyond the schema titles.
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 computes a hash of arbitrary text. It uses specific verb 'calcula' and resource 'hash de un texto arbitrario'. It distinguishes itself from siblings like 'calcular_hash' by focusing on text, but does not explicitly differentiate.
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 explicit use cases: data integrity verification, value comparison, and identifier creation. Does not state when not to use or mention alternatives, 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.
Codifica un texto en Base64 (standard o URL-safe).
Args: texto: texto a codificar url_safe: usar variante URL-safe (reemplaza +/ por -_, sin padding)
| Name | Required | Description | Default |
|---|---|---|---|
| texto | Yes | ||
| url_safe | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description explains the two encoding variants and their effects (character replacements and padding removal). However, it does not mention return type, error handling, or behavior with non-ASCII text, which are relevant for a text encoding tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: a one-sentence summary followed by a clean Args list. Every sentence is necessary and 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 low complexity and presence of output schema, description covers key aspects. However, it could mention that it encodes text (not binary) and that the output is a string, but the output schema likely fills that gap. Minor completeness gap for non-ASCII text handling.
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 0% schema coverage, description fully defines both parameters: 'texto' as the text to encode and 'url_safe' as the option to use URL-safe variant with specific character changes. This adds significant value beyond the schema's type-only definitions.
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?
Description uses specific verb 'codifica' and resource 'texto', and clearly distinguishes between standard and URL-safe Base64 variants. This differentiates it from sibling tool decodificar_base64 and others.
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?
Implies usage for encoding text to Base64, but lacks explicit guidance on when to choose URL-safe vs standard, or when not to use it (e.g., for binary data). No mention of alternatives beyond the listed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Realiza consultas DNS para un dominio.
Soporta registros: A (IPv4), AAAA (IPv6), MX (mail), NS (nameservers), TXT (SPF, DKIM, verificación), CNAME (alias).
Args: dominio: dominio a consultar (ej: "google.com") tipo: tipo de registro DNS — A, AAAA, MX, NS, TXT, CNAME
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | A | |
| dominio | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks information about behavioral traits such as idempotency, side effects, rate limits, or authentication needs. It only describes the function, not the behavior or safety profile.
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 concise, front-loaded with the main purpose, and uses bullet points for record types. Every sentence adds value without redundancy.
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 DNS lookup tool with two parameters and an output schema, the description covers the essential information (domain, record types). It does not address error handling or timeouts, but remains sufficiently complete.
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 description adds meaning beyond the input schema by providing examples ('google.com') and enumerating supported DNS record types for the 'tipo' parameter. This compensates for the 0% schema description coverage.
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 'Realiza consultas DNS para un dominio' and lists supported record types (A, AAAA, MX, NS, TXT, CNAME). This distinguishes it from siblings like whois_dominio and verificar_certificado_ssl.
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 implicitly indicates usage for DNS lookups and lists record types, but does not explicitly state when to use this tool versus alternatives (e.g., whois_dominio for domain registration info) or 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.
Decodifica texto en Base64 (soporta standard, URL-safe, con o sin padding).
Args: texto: texto en Base64 a decodificar
| Name | Required | Description | Default |
|---|---|---|---|
| texto | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses support for multiple Base64 formats (standard, URL-safe, padding variants), which adds behavioral context. However, it does not mention error behavior, output encoding, or whether the input must be a valid string, leaving gaps for an agent.
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 extremely concise: one line for purpose plus a brief parameter explanation. No redundant sentences, and the structure is front-loaded with the main action. Every sentence adds value.
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 (one parameter, output schema exists), the description covers the core behavior and supported formats. It could mention that the output is the decoded string (implied by the tool name) and potentially the encoding, but the current version is largely complete.
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 has 0% description coverage, so the description must compensate. The 'Args' section explains that the parameter 'texto' is the Base64 text to decode, adding meaning beyond the schema's title 'Texto'. This is sufficient for a single-parameter tool.
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 it decodes Base64 text and specifies support for standard, URL-safe, and padding variants. The verb 'decodificar' and resource 'Base64' make the action unambiguous, and it naturally distinguishes from the sibling tool 'codificar_base64' (encode).
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 for decoding Base64 text but does not explicitly state when to use this tool versus alternatives (e.g., 'codificar_base64' for encoding). No exclusions or prerequisite conditions are mentioned, leaving the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escanea ~35 puertos TCP comunes de un host. Solo sobre sistemas propios o autorizados.
Detecta servicios web, SSH, bases de datos, Docker, Kubernetes, SMB, Redis, MongoDB, Elasticsearch y otros. Marca servicios de alto riesgo con consejos.
Args: host: dirección IP o dominio a escanear (ej: "192.168.1.1", "miservidor.com") timeout: tiempo de espera por puerto en segundos (default: 0.5)
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 tool scans ~35 common TCP ports, detects specific services, and marks high-risk ones with advice. This covers key behavioral traits for a port-scanner, though it could mention stealthiness or concurrency.
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 highly concise: a single sentence for purpose, a list of detectable services, and a clear Args block. All sentences add value with no redundancy. The purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (common port scan with ~35 ports) and the existence of an output schema, the description fully covers parameters, behavioral notes, usage restrictions, and detected services. No additional information seems necessary.
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 0%, so the description is essential. It explains 'host' as 'dirección IP o dominio a escanear' with examples, and 'timeout' as 'tiempo de espera por puerto en segundos (default: 0.5)', adding meaning beyond the schema's type and default.
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 'Escanea ~35 puertos TCP comunes de un host', specifying the action (scans), resource (~35 common TCP ports), and subject (host). It also distinguishes from sibling tools, none of which perform port scanning, making the purpose unambiguous.
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: 'Solo sobre sistemas propios o autorizados' restricts usage to authorized systems. It lists detected services, informing the agent what information can be obtained. Although it does not explicitly compare to alternatives, no sibling tool performs similar scanning, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el espacio total, usado y libre (en GB) de una ruta del sistema.
Args: ruta: ruta del sistema de archivos a inspeccionar
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | No | / |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the operation is reading disk space and returning values in GB. Although no annotations are provided, the behavior is straightforward and no hidden side effects are suggested.
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 extremely concise with two sentences and a parameter list. Every word is necessary and no extraneous information 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?
Given the tool's simplicity, the presence of an output schema (not shown) covers return format. The description sufficiently explains the tool's purpose and parameter. No additional context is needed.
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 single parameter 'ruta' has a default value and a title in the schema. The docstring adds a brief description, but it does not substantially enhance understanding beyond the schema. Schema coverage is 0%, but the tool is simple.
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 specifically states it returns total, used, and free disk space in GB for a system path. This clearly distinguishes it from sibling tools like 'info_sistema' or 'listar_directorio'.
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 on when to use this tool compared to alternatives. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera una contraseña criptográficamente segura usando el módulo secrets de Python.
Args: longitud: número de caracteres (entre 8 y 128, default: 16) mayusculas: incluir letras mayúsculas numeros: incluir dígitos 0-9 simbolos: incluir símbolos especiales (!@#$%...)
| Name | Required | Description | Default |
|---|---|---|---|
| numeros | No | ||
| longitud | No | ||
| simbolos | No | ||
| mayusculas | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Mentions cryptographic security via secrets module, but does not discuss rate limits, idempotency, or side effects. Basic transparency, but could be more detailed.
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?
Short header with bullet-like parameter listing. Front-loaded purpose. Could be more concise, but overall efficient. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input parameters well and implies output (a password), but does not describe output format, error conditions, or edge cases (e.g., all flags false). Output schema exists but description doesn't leverage it.
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 0%, so description adds meaning. Explains each parameter (length range, boolean flags for character types) beyond schema names and defaults. Adds context like 'letras mayúsculas' and 'dígitos 0-9'.
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?
Clearly states it generates a cryptographically secure password using Python's secrets module. Distinguishes from sibling tools like 'generar_token_aleatorio' and 'verificar_fortaleza_password'.
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 parameter constraints (length range) but no explicit guidance on when to use this tool vs alternatives or when not to use it. Context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera un token criptográficamente seguro para API keys, secrets, session IDs, etc.
Args: longitud: longitud en bytes de entropía (16-256, default: 32) formato: 'hex' (64 chars para 32 bytes), 'base64', o 'urlsafe'
| Name | Required | Description | Default |
|---|---|---|---|
| formato | No | hex | |
| longitud | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions it generates cryptographically secure tokens using entropy, but lacks details on side effects, authentication needs, or rate limits. It does not contradict any annotations as there are none.
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 two short paragraphs, front-loaded with the purpose, followed by a clear Args section. It is concise with no wasted words, though could be slightly more compact.
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 that the tool has an output schema (so return values are covered) and only two simple parameters, the description adequately covers token generation, parameter constraints, and formats. It could mention error conditions but is otherwise complete.
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 has 0% description coverage, so the description fully explains both parameters. It gives the range and default for 'longitud' (16-256 bytes, default 32) and the three formats (hex, base64, urlsafe) with an example for hex (64 chars for 32 bytes), adding significant meaning.
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 it generates cryptographically secure tokens for API keys, secrets, session IDs, etc. The verb 'generar' and resource 'token' are specific, and it distinguishes itself from siblings like generar_password_seguro by targeting token use cases.
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 lists intended use cases (API keys, secrets, session IDs) but does not explicitly state when not to use it or provide comparisons to sibling tools like generar_password_seguro or hash functions. Guidance is implied but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Realiza una petición HTTP completa y devuelve status, headers y body.
Útil para probar APIs REST, analizar respuestas de endpoints, o debuggear servicios web directamente desde la conversación.
Args: url: URL de destino metodo: método HTTP — GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS headers_json: headers adicionales como JSON (ej: '{"Authorization":"Bearer tok"}') body: cuerpo de la petición (JSON string para POST/PUT/PATCH) timeout: tiempo de espera en segundos (1-60)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| body | No | ||
| metodo | No | GET | |
| timeout | No | ||
| headers_json | No | {} |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns status, headers, and body, and lists all parameters with their behavior (e.g., timeout range 1-60, methods allowed). It does not mention side effects (likely none) or error handling, but for an HTTP request tool this is sufficient.
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 relatively concise: two sentences for purpose, then a labeled list of parameters. It front-loads the main action and use cases. Could be slightly more structured, but it is clear and to the point.
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 has 5 parameters (1 required) and an output schema exists. The description explains the function and all parameters adequately. It could include an example or note about JSON handling, but it is complete enough for an agent to understand and use the tool 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 coverage is 0%, but the description's docstring provides explanations for all 5 parameters: url, metodo (lists methods), headers_json (example JSON), body (for POST etc.), timeout (range). This adds significant meaning beyond the schema, though defaults and constraints are already in 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?
The description clearly states the tool's purpose: 'Realiza una petición HTTP completa y devuelve status, headers y body.' It specifies use cases (probar APIs REST, analizar respuestas, debuggear servicios) and the resource is an HTTP request. The sibling tools are all different network/utility tools, so this tool is clearly distinguished as the HTTP request 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 explains when to use the tool (testing REST APIs, analyzing responses, debugging web services). It does not explicitly state when not to use it or mention alternatives, but the sibling tools are distinct enough that there is no ambiguity. A clear usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve información del sistema operativo: SO, versión, arquitectura y Python.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It clearly indicates the tool is for reading system information, implying no destructive side effects. No contradictions exist, and the behavior is straightforward, though it could explicitly state it is a read-only operation.
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 with no superfluous words, efficiently conveying the tool's purpose and output 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?
Given the tool has no parameters and an output schema exists, the description sufficiently explains the returned data. However, it could be slightly more detailed (e.g., mentioning the output format).
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 has no parameters (100% coverage), so the description adds value by specifying that the output includes SO, version, architecture, and Python. This clarifies what the tool returns beyond the empty 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?
The description clearly states the tool returns operating system information including SO, version, architecture, and Python. This is specific and distinguishes it from sibling tools like analizar_jwt or generar_hash, which serve different purposes.
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 for obtaining OS info, but does not explicitly state when to use this tool versus alternatives or provide any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los archivos y subdirectorios de una carpeta.
Args: ruta: ruta del directorio a listar
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as permissions required, hidden file handling, recursion, or error cases. It only states the basic function, leaving the agent without important 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 very concise with two sentences and an Args block, but lacks structure. It is front-loaded with purpose but incomplete; every sentence could be more informative. It is not overly verbose, but missing critical details.
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 existence of an output schema, the description remains incomplete. It does not specify whether listing is recursive, how dotfiles are treated, or what the output format includes. The output schema may fill some gaps, but behavioral context is lacking.
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 0%. The parameter 'ruta' is described only as 'ruta del directorio a listar', which merely restates the parameter name. This adds minimal value beyond the schema; the description fails to clarify format, allowed values, or default behavior.
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 lists files and subdirectories of a folder, with a specific verb 'Lista' and resource 'archivos y subdirectorios de una carpeta'. It distinguishes itself from sibling tools which are unrelated (e.g., network, security, encoding).
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 on when to use this tool vs alternatives. There is no mention of prerequisites, exclusions, or context. The description only explains the parameter 'ruta' without providing usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspecciona el certificado SSL/TLS de un dominio.
Devuelve: estado de validez, días hasta expiración, protocolo, cifrado, emisor (CA), organización, fechas y Subject Alternative Names (SANs). Detecta certificados expirados o próximos a vencer.
Args: dominio: hostname a inspeccionar (ej: "google.com", "miservidor.com") puerto: puerto HTTPS (por defecto 443)
| Name | Required | Description | Default |
|---|---|---|---|
| puerto | No | ||
| dominio | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists outputs but does not disclose behavioral traits such as network connectivity, error handling, timeouts, or whether it accepts IP addresses. The description lacks details on side effects or prerequisites.
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 concise, with a clear verb-led first sentence, a bullet-like list of returns, and a separate args section. Every sentence adds value without redundancy.
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 description covers input parameters and expected outputs sufficiently. Minor gaps include lack of error explanations or edge cases (e.g., invalid domains). Given the output schema exists, the description adequately supports tool selection and invocation.
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 has 0% description coverage, but the description compensates with an 'Args' section that clarifies each parameter, including examples for 'dominio' and default value for 'puerto'. This adds significant meaning beyond the schema's bare type and title.
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 inspects SSL/TLS certificates of a domain and lists the specific return fields (validity, expiration, cipher, etc.). The name and description together uniquely identify the tool's purpose among sibling tools like consultar_dns or whois_dominio.
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 for certificate inspection but does not explicitly state when to use this tool versus alternatives. No exclusions or comparison with sibling tools like escanear_puertos or verificar_headers_seguridad are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evalúa la fortaleza de una contraseña con análisis de entropía y patrones débiles.
No almacena ni transmite la contraseña. Evalúa: longitud, diversidad de caracteres, patrones débiles comunes, repetición y entropía estimada en bits.
Args: password: la contraseña a evaluar
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses important behavioral traits: no storage or transmission of the password, and lists evaluation criteria. This adds value beyond the input schema.
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 concise and front-loaded, with no wasted words. It immediately states the purpose, then adds key details in a structured manner.
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 description covers input, behavioral guarantee, and evaluation criteria. Although output structure is not detailed, the existence of an output schema mitigates this. Adequately complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section describes the single parameter as 'la contraseña a evaluar', compensating for 0% schema description coverage. This adds meaning beyond the schema's type and title.
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 evaluates password strength with entropy and weak pattern analysis, using specific verbs and resources. It distinguishes well from siblings like analizar_jwt or calcular_hash.
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 context is clear: use when needing to check password strength. No explicit exclusions or alternatives, but the uniqueness among siblings makes usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audita los HTTP security headers de una URL y puntúa su nivel de seguridad.
Verifica: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Detecta fugas de información (Server, X-Powered-By).
Args: url: URL a auditar (ej: "https://miapp.com" o directamente "miapp.com")
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists what headers are checked and mentions detection of information leaks, but does not disclose how scoring works, whether it is read-only, or any side effects.
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 front-loaded with purpose, followed by a list and args section. It is efficient with no wasted words, though could be slightly more 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?
Given the presence of an output schema (not shown), the description adequately covers what the tool checks and detects. It is complete enough for a scanning tool with a single parameter.
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 single parameter 'url' has 0% schema description coverage, so the description adds clarity by specifying URL format (with or without https). This provides meaning 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?
The description clearly states the tool audits HTTP security headers of a URL and scores security level, listing specific headers checked. The verb 'audita' is specific, and it is clearly distinct from siblings like 'verificar_certificado_ssl' or 'analizar_jwt'.
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 checking HTTP security headers but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or context cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta información WHOIS de un dominio.
Devuelve: registrante, registrador, fechas de creación/expiración/actualización, nameservers y estado del dominio.
Args: dominio: dominio a consultar (ej: "google.com", "openai.com")
| Name | Required | Description | Default |
|---|---|---|---|
| dominio | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as rate limits, authentication requirements, or error handling. While it lists return fields, it lacks transparency on operational constraints.
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 concise, well-structured with a clear example and bullet points for return data. Every sentence adds value without verbosity.
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 single-parameter tool with an output schema, the description covers the return fields adequately. However, it omits error scenarios or potential rate limits, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds meaning by specifying the parameter 'dominio' with examples ('google.com', 'openai.com') and context, significantly enhancing understanding 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?
The description clearly states 'Consulta información WHOIS de un dominio' with a specific verb and resource. It distinguishes from sibling tools like 'consultar_dns' which performs DNS lookups, not WHOIS queries.
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 explains what the tool does but does not provide explicit guidance on when to use it vs alternatives, nor any preconditions or exclusions. Usage is implied but not directly guided.
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.
v0.2.0analizar_jwtcalcular_hashcalcular_hash_textocodificar_base64consultar_dnsdecodificar_base64escanear_puertosespacio_discogenerar_password_segurogenerar_token_aleatoriohacer_request_httpinfo_sistemalistar_directorioverificar_certificado_sslverificar_fortaleza_passwordverificar_headers_seguridadwhois_dominioCada herramienta tiene un propósito claramente diferente: análisis de JWT, hashing, codificación, consultas DNS, escaneo de puertos, generación de contraseñas, etc. No hay superposición significativa.
Todos los nombres siguen el patrón consistente verbo_sustantivo en español, usando snake_case. La convención es uniforme en las 17 herramientas.
17 herramientas es un número adecuado para un conjunto de utilidades de seguridad y sistema. Cubre un rango amplio sin ser excesivo.
El conjunto cubre bien las funcionalidades principales: hashing, codificación, consultas de red, análisis de seguridad. Faltan herramientas para cifrado simétrico o generación de claves, pero lo esencial está presente.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
Claude-powered AI tools: research, write, code, analyze, translate, debate, pitch, score, and more.
CyberShield - 12 cybersecurity tools: NIS2 mapping, MITRE ATT&CK, vulns, threat intel.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GonzaBot/mcp-toolkit-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server