mcp-scorecard

Tres pasos

1. Apunta a un servidor mcp-scorecard scan ./server.py Un archivo Python o un directorio. También hay variantes por capa (footprint / scoping / security / name).
2. Vuelve el scorecard Overall grade: D (ORANGE) · tools=4 Nota general, band por capa, conteo de tokens por herramienta y una lista de findings por capa.
3. Tú recortas --json / --format sarif Salida legible por máquina para CI. Códigos de salida: 0=GREEN/YELLOW, 1=ORANGE, 2=RED.

Ejemplo: un scan real

ejecución real, 2026-07-13: mcp-scorecard scan sobre ~/repos/domain-pre-flight, condensado de la salida real del CLI

Qué pesa el scorecard

Se miden seis ejes sobre la superficie declarada del servidor MCP; no se ejecuta código, solo se lee la salida de tools/list y las docstrings detrás de ella:

• Carga inicial de tokens suma de description + schema + name en todas las herramientas, tiktoken cl100k
• Inflamiento por herramienta desglose de costo por herramienta; descriptions sobre 150 tokens se marcan
• Verbos vagos run / handle / process / manage / execute en descriptions detectados con una pista de acción
• Disparador cuándo-usar cada herramienta se revisa buscando una frase de disparador explícita en su description
• Patrones de secreto barrido regex de AWS / GitHub / OpenAI / Anthropic / Slack / PEM en las descriptions
• Namespace de nombres colisión de case, similitud Levenshtein contra ~50 marcas + 23 MCPs conocidos, variantes de separador

La seguridad en runtime (prompt injection sobre tráfico vivo, wrap de MCP-Scan) y SARIF están en el roadmap para la v0.2; los objetivos por registry (`github:` / `npm:`) quedan para la v0.4. El scorecard v0.1 es honesto respecto a lo que inspecciona: la superficie declarada, no el servidor en ejecución.

Para quién es

• Autores de MCP a punto de publicar y que quieren un barrido de tokens / nombres / secretos antes del release
• Integradores de agentes que evalúan un MCP de terceros antes de añadirlo a una configuración de Claude Code / Cursor
• Revisores de seguridad que quieren una pasada estructural rápida antes de pruebas de runtime más profundas (MCP-Scan, Inspector)
• Lectores de『MCP実践セキュリティ』 que quieren correr las comprobaciones del libro contra sus propios servidores

Cuándo usarlo

• Antes de publicar un nuevo MCP en PyPI o npm: un solo scan saca a la luz descriptions inflamadas y verbos vagos sin especificar
• Antes de añadir un MCP de terceros a tu agente: una lectura estructural rápida sobre costo, secretos e higiene de nombres
• En CI: --json o --format sarif para un gate legible por máquina, con ORANGE/RED como códigos de salida distintos de cero
• Al escribir revisiones al estilo『MCP実践セキュリティ』: las mismas reglas que propone el libro, aplicadas de forma consistente

Instalación

pip install mcp-scorecard              # CLI + library
pip install "mcp-scorecard[mcp]"       # + MCP server (stdio)
mcp-scorecard scan ./server.py

El CLI funciona por sí solo. Añade el extra opcional `[mcp]` para exponer `mcp-scorecard-mcp` como servidor MCP y dejar que un LLM dentro de Claude Code / Cursor / Windsurf audite otros MCPs desde el chat.

Qué mira

• Capa A — Footprint Pasivo: description, schema y name contados con tiktoken por herramienta; initial_token_load sumado; descriptions sobre 150 tokens marcadas como inflamadas
• Capa B — Use-Case Scoping: barrido de verbos vagos (run, handle, process, manage, execute), comprobación de disparador cuándo-usar, detección de solapamiento entre pares de herramientas, consistencia de estilo de nombre (snake / camel / flat)
• Capa C — Reglas propias de Security: barrido regex de claves AWS / GitHub / OpenAI / Anthropic / Slack y bloques PEM en descriptions, comprobación de shadowing contra ls / cat / rm / familia curl, marcadores de injection en docstrings. El wrap de MCP-Scan está planeado para v0.2
• Capa D — Name Safety: detección de colisión de case, similitud Levenshtein contra un conjunto embebido de ~50 marcas y 23 nombres de MCP conocidos, barrido de variantes de separador (mcp_scorecard vs mcp-scorecard), higiene de namespace
• 5 herramientas MCP vía mcp-scorecard-mcp: preflight_scan (las cuatro capas), preflight_footprint, preflight_scoping, preflight_security, preflight_name_check. Todas aceptan una ruta o un manifest JSON, así que los MCPs en TypeScript / Node se soportan vía su manifest

Patrones de seguridad capturados (muestra)

La Capa C corre barridos regex sobre las descripciones de las herramientas y comprobaciones estructurales sobre los nombres. Algunos de los patrones que atrapa, con el arreglo apuntado:

fuente: src/mcp_preflight/rules/security.py · rules/footprint.py (patrones embutidos en v0.1)

Reescrituras que el scorecard sí recompensa

Dos ejemplos de antes/después del tipo de cambio que el scorecard califica más alto:

Uso

# scan completo
mcp-scorecard scan ./server.py

# JSON legible por CI
mcp-scorecard scan ./server.py --json

# registrar como servidor MCP en Claude Code
claude mcp add mcp-scorecard -- mcp-scorecard-mcp

Puntuar, no bloquear

El scorecard es un pre-flight, no un firewall. Puntúa lo que puede inspeccionar de forma estática y señala qué arreglar:

• Cada capa devuelve su propio band (GREEN / YELLOW / ORANGE / RED); la nota general es la peor de las cuatro, así que una sola capa ORANGE baja todo el cartón
• Los findings vienen tipados por severidad ("warn" / "error"), así que el CI puede hacer gate por severidad vía código de salida (0=GREEN/YELLOW, 1=ORANGE, 2=RED)
• La v0.1 inspecciona solo la superficie declarada; el prompt injection en runtime sobre tráfico MCP vivo es el trabajo del wrap de MCP-Scan planeado para v0.2

El contrato de códigos de salida sigue las convenciones de SARIF, así que `mcp-scorecard scan --format sarif` encaja en un gate de seguridad de CI sin pegamento extra.

Auto-comprobación: correr la herramienta contra su propio servidor MCP devuelve nota general D (ORANGE), con 557 tokens repartidos en 5 herramientas, todas las capas menos scoping en verde. Los findings de scoping saltan por verbos vagos (handle / process / manage / execute) porque las docstrings mencionan esos verbos de manera explícita como ejemplos de lo que hay que evitar. Es un falso positivo en ese contexto, y está etiquetado como tal; aun así, la misma vara se aplica a la propia herramienta, sin modificaciones.

Por qué existe esta herramienta

El ecosistema MCP creció más rápido que las reglas de revisión para él. Un solo servidor verboso puede quemar miles de tokens por turno en silencio con solo estar registrado, porque cada description y cada inputSchema van al LLM en cada turno. Las herramientas existentes cubren bien el lado de runtime: MCP-Scan se encarga de injection y shadowing en el momento de la llamada, y MCP Inspector se encarga de la conformidad de protocolo. La superficie orientada al LLM (cuánto cuesta mantener el servidor listado, qué tan bien acotadas están sus herramientas, si sus nombres colisionan con comandos comunes) no tenía un scorecard dedicado. El `mcp-scorecard` llena ese hueco, y lo hace como compañero de las comprobaciones que propone el libro『MCP実践セキュリティ』.

Junto a MCP-Scan y MCP Inspector

Tres herramientas, tres preguntas distintas. La diferencia honesta es qué inspecciona cada una en la práctica:

La raya indica que la herramienta no cubre ese eje, y no que sea peor. MCP-Scan y MCP Inspector son las referencias para seguridad en runtime y depuración de protocolo respectivamente; mcp-scorecard se sitúa antes, en la calidad de la superficie orientada al LLM. Los detalles sobre MCP-Scan y MCP Inspector reflejan el estado de sus docs públicos a 2026-07; los ejes que allí no se mencionan quedan marcados como "—" en vez de adivinarse.

FAQ

Sobre el autor

Creado por Ken Imoto: más de 300 artículos técnicos en Zenn, Qiita, Dev.to y este sitio, más de 40 libros en 4 idiomas, más de 400 mil páginas vistas en Zenn y Qiita, 4 artículos de investigación en Zenodo y creador del LLMO Framework. Las reglas de este scorecard siguen el mismo diseño que las comprobaciones que van al libro próximo a publicarse『MCP実践セキュリティ』(Impress NextPublishing).

Más sobre Ken →

Relacionado

Va de la mano con domain-pre-flight, el CLI + MCP de pre-flight para elegir dominio: misma línea de nomenclatura pre-flight, misma forma dual CLI + MCP, y el scan de muestra de esta página es una ejecución real contra ese repo.

domain-pre-flight →