Skip to main content
Glama

Spec Score MCP

Score your specs before Claude builds from them.

A balanced spec produces balanced code. An unbalanced spec produces creative fiction.

The problem

When your spec is detailed on some axes but vague on others, Claude doesn't ask for clarification — it fills in the blanks. The result compiles, the tests pass, but it's not what you meant.

This tool catches that before you start building. It scores your spec on 4 axes, tells you which one is weakest, and gives you a concrete tip to fix it.

Related MCP server: MCP Prompt Optimizer

4 axes

Axis

Question it answers

completeness

Can Claude understand the full scope of what to build?

clarity

Is there only one way to interpret this spec?

constraints

Does Claude know what NOT to build?

specificity

Are there concrete, testable details?

Each axis scores 0.0 to 1.0. The balance score measures how evenly the 4 axes are covered.

Balance matters more than individual scores. A spec scoring 0.50 on all 4 axes (balance: 0.97) will produce better output than one scoring 0.95 / 0.95 / 0.20 / 0.90 (balance: 0.58). Why? That one weak axis — constraints at 0.20 — is exactly where Claude will improvise. You described what to build in detail, but forgot to say what's out of scope. So Claude builds everything you asked for, plus features you didn't.

On the radar chart: an even diamond beats a sharp spike.

Verdicts

Verdict

What it means

SHIP IT

Spec is ready — Claude knows what to build and what not to

ALMOST

One axis needs a small fix before you start

DRAFT

Multiple axes need work, but the structure is there

VAGUE

Well-organized but too abstract to act on

UNBOUNDED

Clear goal but no boundaries — Claude will over-build

OVER-CONSTRAINED

Lots of rules but unclear what the actual goal is

SKETCH

Starting point — needs detail on most axes

Not SHIP IT yet? The tool tells you which axis is weakest and what to add. Fix that axis, re-score, repeat. Most specs reach SHIP IT in 2-3 rounds.

Install

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.js

The 3 tools are now available in every Claude Code session.

Usage

Slash commands

Clone this repo to get the built-in slash commands:

/project:scan my-feature-spec.md

Reads the file, scores it, and writes a my-feature-spec.md.scored.md with scores, verdict, tip, and a radar chart.

/project:compare blueprint.md implementation.md

Scores both files and writes a compared.scored.md with side-by-side radar charts.

Direct tool use

The 3 MCP tools work in any Claude Code conversation:

Tool

What it does

spec_score

Scores a spec on 4 axes, returns balance score and verdict

spec_visualize

Generates an SVG radar chart from scores

spec_compare

Side-by-side comparison of two scored specs

Ask Claude: "Score this spec", "Show me the radar chart", or "Compare these two specs".

Example: from UNBOUNDED to SHIP IT

This tool scoring its own spec — four rounds, each fixing the weakest axis:

Round 1: the idea

Build a spec scoring tool

UNBOUNDED  0.12  Tip: What does 'scoring' mean? What axes? What output?

One axis is high (clarity — the goal is clear), everything else is near zero. Claude would build... anything. A web app? A CLI? A VS Code extension? No way to know.

Round 2: add context

Build an MCP server that scores specs on 4 axes: completeness, clarity, constraints, specificity. Each axis is 0.0-1.0. Returns a balance score and verdict.

ALMOST  0.67  Tip: What are the verdicts? What does the tool NOT do?

Now Claude knows what to build. But constraints are still weak — it might add auto-fixing, CI integration, a database.

Round 3: add boundaries

Three tools: spec_score, spec_visualize, spec_compare. Non-goals: no auto-fixing, no CI integration, no storage.

SHIP IT  0.84  Tip: Add testable criteria — what balance maps to which verdict?

Crossed the threshold. Claude now knows what to build AND what not to build. Specificity is still the weakest axis.

Round 4: add testable details

Balance = 1 - sqrt(variance)/mean. SHIP IT > 0.75, ALMOST > 0.60, plus pattern-based verdicts. Node.js, MCP SDK, stdio transport.

SHIP IT  0.95  Spec is ready for implementation.

Four rounds: 0.12 → 0.67 → 0.84 → 0.95. Each round fixed exactly one thing.

The math

  1. Claude scores each axis (0.0 - 1.0)

  2. Normalize the vector: v / ||v||

  3. Balance: 1 - sqrt(variance) / mean

  4. Verdict: balance threshold + axis pattern matching

The scoring intelligence comes from Claude, not from the algorithm. The algorithm only measures balance.

Project structure

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 command

OpenPoem — spec-score-mcp

MIT License.

© 2026 OpenPoem. info@openpoem.org

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv2.0.2
    • First observedspec_compare
    • First observedspec_score
    • First observedspec_visualize

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive
ResponsivenessSlow

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A Spec-Driven Development toolkit that transforms LLMs into development agents by providing expert-crafted prompts for generating structured specifications and validating documents across the Requirements → Design → Tasks → Code workflow.
    1
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    Automatically analyzes and optimizes AI prompts by calculating clarity scores, detecting risks, asking clarifying questions, and adding domain-specific requirements to improve AI interaction quality.
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/openpoem/spec-score-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server