Evalúa tus especificaciones antes de que Claude las convierta en código.
Una especificación equilibrada produce código equilibrado. Una especificación desequilibrada produce ficción creativa.
Cuando tu especificación es detallada en algunos ejes pero vaga en otros, Claude no pide aclaraciones; simplemente rellena los espacios en blanco. El resultado compila y las pruebas pasan, pero no es lo que tenías en mente.
Esta herramienta detecta esto antes de que empieces a construir. Califica tu especificación en 4 ejes, te indica cuál es el más débil y te da un consejo concreto para solucionarlo.
Related MCP server: MCP Prompt Optimizer
Eje | Pregunta que responde |
integridad | ¿Puede Claude entender el alcance completo de lo que hay que construir? |
claridad | ¿Hay una sola forma de interpretar esta especificación? |
restricciones | ¿Sabe Claude qué NO construir? |
especificidad | ¿Hay detalles concretos y comprobables? |
Cada eje se califica de 0.0 a 1.0. La puntuación de equilibrio mide qué tan uniformemente cubiertos están los 4 ejes.
El equilibrio importa más que las puntuaciones individuales. Una especificación con 0.50 en los 4 ejes (equilibrio: 0.97) producirá mejores resultados que una con 0.95 / 0.95 / 0.20 / 0.90 (equilibrio: 0.58). ¿Por qué? Ese eje débil —restricciones en 0.20— es exactamente donde Claude improvisará. Describiste qué construir en detalle, pero olvidaste decir qué queda fuera del alcance. Así que Claude construye todo lo que pediste, además de funciones que no querías.
En el gráfico de radar: un diamante uniforme es mejor que una punta afilada.
Veredicto | Qué significa |
SHIP IT | La especificación está lista: Claude sabe qué construir y qué no |
ALMOST | Un eje necesita un pequeño ajuste antes de empezar |
DRAFT | Varios ejes necesitan trabajo, pero la estructura está ahí |
VAGUE | Bien organizada pero demasiado abstracta para actuar sobre ella |
UNBOUNDED | Objetivo claro pero sin límites: Claude construirá de más |
OVER-CONSTRAINED | Muchas reglas pero no está claro cuál es el objetivo real |
SKETCH | Punto de partida: necesita detalles en la mayoría de los ejes |
¿Aún no es SHIP IT? La herramienta te dice qué eje es el más débil y qué añadir. Corrige ese eje, vuelve a calificar y repite. La mayoría de las especificaciones llegan a SHIP IT en 2-3 rondas.
git clone https://github.com/openpoem/spec-score-mcp.git
cd spec-score-mcp && npm install && npm run build
claude mcp add spec-score -- node $(pwd)/dist/mcp.jsLas 3 herramientas ahora están disponibles en cada sesión de Claude Code.
Clona este repositorio para obtener los comandos de barra integrados:
/project:scan my-feature-spec.mdLee el archivo, lo califica y escribe un my-feature-spec.md.scored.md con las puntuaciones, el veredicto, el consejo y un gráfico de radar.
/project:compare blueprint.md implementation.mdCalifica ambos archivos y escribe un compared.scored.md con gráficos de radar comparativos.
Las 3 herramientas MCP funcionan en cualquier conversación de Claude Code:
Herramienta | Qué hace |
| Califica una especificación en 4 ejes, devuelve la puntuación de equilibrio y el veredicto |
| Genera un gráfico de radar SVG a partir de las puntuaciones |
| Comparación lado a lado de dos especificaciones calificadas |
Pregúntale a Claude: "Score this spec", "Show me the radar chart" o "Compare these two specs".
Esta herramienta calificando su propia especificación: cuatro rondas, cada una corrigiendo el eje más débil:
Construir una herramienta de calificación de especificaciones
UNBOUNDED 0.12 Tip: What does 'scoring' mean? What axes? What output?Un eje es alto (claridad: el objetivo es claro), todo lo demás está cerca de cero. Claude construiría... cualquier cosa. ¿Una aplicación web? ¿Una CLI? ¿Una extensión de VS Code? No hay forma de saberlo.
Construir un servidor MCP que califique especificaciones en 4 ejes: integridad, claridad, restricciones, especificidad. Cada eje es 0.0-1.0. Devuelve una puntuación de equilibrio y un veredicto.
ALMOST 0.67 Tip: What are the verdicts? What does the tool NOT do?Ahora Claude sabe qué construir. Pero las restricciones siguen siendo débiles: podría añadir corrección automática, integración con CI, una base de datos.
Tres herramientas: spec_score, spec_visualize, spec_compare. Objetivos no incluidos: sin corrección automática, sin integración con CI, sin almacenamiento.
SHIP IT 0.84 Tip: Add testable criteria — what balance maps to which verdict?Cruzó el umbral. Claude ahora sabe qué construir Y qué no construir. La especificidad sigue siendo el eje más débil.
Equilibrio = 1 - sqrt(varianza)/media. SHIP IT > 0.75, ALMOST > 0.60, más veredictos basados en patrones. Node.js, MCP SDK, transporte stdio.
SHIP IT 0.95 Spec is ready for implementation.Cuatro rondas: 0.12 → 0.67 → 0.84 → 0.95. Cada ronda corrigió exactamente una cosa.
Claude califica cada eje (0.0 - 1.0)
Normalizar el vector: v / ||v||
Equilibrio: 1 - sqrt(varianza) / media
Veredicto: umbral de equilibrio + coincidencia de patrones de ejes
La inteligencia de calificación proviene de Claude, no del algoritmo. El algoritmo solo mide el equilibrio.
src/
mcp.ts # MCP server (3 tools)
score.ts # Scoring engine
visualize.ts # SVG radar charts
.claude/
commands/
scan.md # /project:scan command
compare.md # /project:compare commandOpenPoem — spec-score-mcp
Licencia MIT.
© 2026 OpenPoem. info@openpoem.org
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.2spec_comparespec_scorespec_visualizeScored across 3 tools
The tools have overlapping purposes that could cause confusion. spec_score and spec_visualize both score a spec on the same four axes and provide the same analysis, making them nearly redundant. Only spec_compare has a clearly distinct function by comparing two specs, but the other two tools are ambiguous in their differentiation.
The naming follows a consistent pattern with all tools using the prefix 'spec_' followed by a verb (compare, score, visualize). This makes the purpose of each tool predictable and readable, though the similarity in naming between spec_score and spec_visualize contributes to the disambiguation issue.
With 3 tools, the count is reasonable for a server focused on spec evaluation. It covers core functions like scoring, comparing, and visualizing specs, which aligns well with the server's purpose, though the overlap between spec_score and spec_visualize suggests the set could be streamlined without losing functionality.
The tool surface is mostly complete for spec evaluation, covering scoring, comparison, and visualization. However, there is a notable gap in tools for editing or updating specs based on the analysis, which could limit workflow coverage. The redundancy between spec_score and spec_visualize also indicates inefficiency rather than a functional gap.
PQS scores any prompt before the model runs. 8 dimensions. 5 frameworks. Pre-flight, not post-hoc.
Generate and validate a .specs/ bundle for your repo, then hand it to your AI coding agent
Commission a multi-model AI spec committee from your agent; get rubric-scored, build-ready specs.
Checks llms.txt, AI crawler access in robots.txt, and sitemap - with a 0-100 AI readiness score.
