How do I use spec-to-delivery?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@spec-to-delivery parse examples/requirements.md and generate a traceability matrix" 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.

spec-to-delivery

by medhakara

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

spec-to-delivery

Claude Agent Skills and an MCP server that turn a requirements document into an RFC, functional test scenarios, and a traceability matrix that proves every requirement has a test.

Built from a pattern I used on a 25-person enterprise platform team, where RFCs and test scenarios were the most repetitive engineering work in every sprint. The agent drafts, the engineer reviews. The tools in this repo are the deterministic part that keeps the agent honest: they parse, diff and cross-check so the model cannot quietly skip a requirement.

What is in the box

Piece	What it does
`skills/rfc-from-requirements`	Claude Agent Skill: requirements in, structured RFC draft out, with a requirement trace table
`skills/functional-test-scenarios`	Claude Agent Skill: writes Gherkin scenarios tagged with requirement IDs and verifies 100 percent coverage
MCP server (`src/`)	Four tools: `parse_requirements`, `diff_requirements`, `parse_scenarios`, `traceability_matrix`
`examples/`	A small rebate-accrual requirements doc and a feature file to try it on

Related MCP server: IEC 62304 Requirements MCP Server

Quick start

git clone https://github.com/medhakara/spec-to-delivery
cd spec-to-delivery
npm install
npm test
npm run build

Register the MCP server with Claude Code

claude mcp add spec-to-delivery -- node /absolute/path/to/spec-to-delivery/dist/index.js

Or in .mcp.json at your project root:

{
  "mcpServers": {
    "spec-to-delivery": {
      "command": "node",
      "args": ["/absolute/path/to/spec-to-delivery/dist/index.js"]
    }
  }
}

Install the skills

Copy the two folders under skills/ into your project's .claude/skills/ (or ~/.claude/skills/ for every project). Claude Code picks them up automatically.

Try it

In Claude Code, inside this repo:

Use the functional-test-scenarios skill on examples/requirements.md, starting from examples/accruals.feature.

The example feature file deliberately covers only five of the nine requirements, so you can watch the skill find the gaps, write the missing scenarios, and re-run the traceability check until coverage is 100 percent.

Then:

Use the rfc-from-requirements skill to draft an RFC for REQ-010 through REQ-012.

Requirement format

Any Markdown line that starts with an ID such as REQ-001, FR-12, NFR-3 or US-045 is a requirement. List items, bold IDs and headings all work:

- REQ-001: The system MUST compute accruals only inside the program period.
- **REQ-002** Accruals SHOULD be recalculated when a transaction is amended.
  Continuation lines are joined to the requirement above.
### REQ-003 Claim validation

Priority is read from MUST / SHALL / SHOULD / MAY / COULD in the text or a trailing [MUST] tag. The section is the nearest heading. Duplicate IDs are flagged, not merged.

Scenario linking

A scenario is linked to a requirement by a @REQ-001 tag above it, or by mentioning the ID in its title. Feature-level tags apply to every scenario in the feature.

Tool reference

All tools accept { "text": "..." } or { "path": "..." } for each document.

parse_requirements { document } → [{ id, text, section, priority, line }]
diff_requirements { before, after } → { added, removed, changed: [{id, before, after}], unchanged }
parse_scenarios { features: [document] } → [{ feature, name, requirementIds, line }]
traceability_matrix { requirements, features: [document] } → { rows, uncovered, orphanScenarios, unknownIds, coverage, markdown }

Inspect interactively with npm run inspect.

Why deterministic tools around an LLM

The skills tell the model what good looks like. The tools make it checkable. A model that "believes" it covered every requirement is not the same as a matrix that shows it did, and reviewers trust the matrix. The same split (LLM drafts, code verifies) is how I structure every agent that ships to production.

Roadmap

Excel and Jira export as requirement sources
Coverage gate for CI (spec-to-delivery check --min 100)
ADR skill sharing the same trace table

Licence

MIT. Kumar Gautam, 2026.

Built by Kumar Gautam at Medhakara, an AI engineering studio.

Available Tools

4 tools

diff_requirementsA

Compare two versions of a requirements document by requirement ID. Returns added, removed, changed (with before/after text) and unchanged IDs.

ParametersJSON Schema

Name	Required	Description	Default
`after`	Yes
`before`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of explaining behavior. It does disclose return categories (added, removed, changed with before/after text, unchanged IDs), which is useful. However, it omits behavioral details such as whether file paths or inline text are supported, how missing IDs are handled, or whether the operation is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and resource, then efficiently lists the output categories. Every part contributes useful information 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.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two nested object parameters and no output schema, the description does a reasonable job of explaining what is returned. However, it does not clarify how to provide the two versions (path vs. text), what counts as 'changed' beyond ID matching, or any edge cases. The schema fills some gaps, but the overall context is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate by explaining parameter semantics. It only adds 'by requirement ID', which helps with the comparison key, but does not explain the structure of `before` and `after` or the path/text input modes. The agent must rely entirely on the schema for parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Compare') and resource ('two versions of a requirements document'), and specifies the comparison key ('by requirement ID'). It also enumerates precise output categories, making the tool's purpose unambiguous and distinct from sibling tools like parse_requirements or traceability_matrix.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when an agent needs to compare two versions of a requirements document, which is clear enough. However, it does not explicitly state when to prefer this tool over siblings, nor does it mention any exclusions or prerequisites such as requiring the documents to contain requirement IDs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

parse_requirementsA

Extract identified requirements (REQ-001 style IDs) from a Markdown requirements document. Returns id, text, section, priority and line number for each.

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It usefully discloses the output shape (id, text, section, priority, line number) and input format (Markdown), but it does not state whether the operation is non-mutating, how it handles malformed documents, or what happens when no REQ IDs are found. The word 'extract' implies read-only, and the return disclosure adds value, but deeper behavioral context is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action, input, and return fields without wasted words. Every clause adds useful information, and it is appropriately sized for a simple extraction tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, and the description covers the return fields but omits the key invocation detail: how to supply the document via 'path' or 'text'. Correctly invoking the tool requires understanding this either-or input, so the definition is incomplete despite being readable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the parameter semantics. It does not mention that 'document' accepts either a 'path' or 'text', nor when one should be preferred over the other. This is a significant gap because the nested parameter structure is the sole input and is not explained in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Extract') with a specific resource ('identified requirements ... from a Markdown requirements document') and names the exact ID style (REQ-001) and return fields. This clearly positions it against siblings like parse_scenarios and diff_requirements, so an agent can tell them apart without inspecting other tool definitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when you need to pull REQ-001 style IDs from a Markdown document, but it gives no explicit when/when-not guidance or mention of alternatives. The context is clear enough, but exclusions are left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

parse_scenariosA

Parse Gherkin feature text and return each scenario with the requirement IDs it is linked to (via @REQ-001 tags or IDs in the scenario title).

ParametersJSON Schema

Name	Required	Description	Default
`features`	Yes	One or more .feature documents

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the core extraction logic (requirement IDs found via @REQ-001 tags OR scenario title IDs), which is the key behavior. However, it does not disclose edge cases (malformed Gherkin, unmatched scenarios), the file-vs-text input distinction present in the schema, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with zero wasted words. It states the action, the input, the output, and the extraction mechanisms compactly. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and full schema coverage, input handling is well covered. The main gap is the unspecified output format - there is no output schema, and the description only says it 'returns each scenario' conceptually without describing the returned structure. Since no annotations exist either, an agent would not know the exact shape of the returned scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% - the single 'features' parameter and its nested 'path'/'text' properties are all documented in the schema. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline of 3 for high-coverage schemas applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Parse), a specific resource (Gherkin feature text), and a clear output (scenarios with linked requirement IDs via @REQ-001 tags or title IDs). This clearly distinguishes it from siblings like parse_requirements (which parses requirement documents, not feature files) and diff_requirements/traceability_matrix (which operate on parsed artifacts, not raw Gherkin).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied by the purpose: an agent can infer this tool is for extracting scenarios from Gherkin feature documents. However, there is no explicit guidance about when to use this tool versus parse_requirements (e.g., when you only need requirement specs, not scenarios) or when NOT to use it. No alternatives or exclusions are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

traceability_matrixC

Build a requirement-to-scenario traceability matrix. Returns per-requirement coverage, uncovered requirement IDs, orphan scenarios, unknown IDs, a coverage percentage, and a ready-to-paste Markdown table.

ParametersJSON Schema

Name	Required	Description	Default
`features`	Yes
`requirements`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses output contents but does not explain input expectations, side effects (likely none, but not stated), error handling, or the meaning of terms like 'unknown IDs' and 'orphan scenarios'. It also doesn't state whether the tool is read-only or modifies anything.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the main purpose and lists outputs. It is efficient with no filler. However, it could be more structured by separating the purpose from the output list, but overall it is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with nested object parameters and no output schema, the description is incomplete. It explains what the tool returns but not how to provide inputs, what constraints apply (e.g., ID formats, matching requirements to scenarios), or any prerequisites. An agent would struggle to know what to pass in, making the tool difficult to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero descriptions for the top-level parameters 'requirements' and 'features' (coverage 0%), and the description does not compensate. It doesn't explain what these parameters represent, how they relate to each other, or what data format is expected. The description only focuses on outputs, leaving input semantics entirely undefined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Build a requirement-to-scenario traceability matrix.' It also lists the specific outputs (coverage, uncovered IDs, orphan scenarios, unknown IDs, percentage, Markdown table), which further clarifies what the tool produces. This distinguishes it from sibling tools like parse_requirements and diff_requirements, which focus on parsing and comparing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 versus the siblings (parse_requirements, diff_requirements, parse_scenarios). There is no mention of prerequisites (e.g., needing parsed requirement or scenario data) or situations where this tool is appropriate. The context is implied by the purpose but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 23, 2026
- First observeddiff_requirements
- First observedparse_requirements
- First observedparse_scenarios
- First observedtraceability_matrix

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-09-23 17:55 across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: parsing requirements, diffing requirements, parsing scenarios, and building a traceability matrix. There is no overlap or ambiguity; an agent can easily select the correct tool for a specific task.

Naming Consistency4/5

The first three tools follow a consistent verb_noun pattern (parse_requirements, diff_requirements, parse_scenarios), but traceability_matrix is a noun phrase rather than a verb_action. This minor deviation is easily readable but slightly inconsistent.

Tool Count5/5

Four tools is well within the ideal range and each tool covers a distinct stage of the requirements-to-scenario workflow. The scope is focused and every tool earns its place.

Completeness4/5

The tool set covers parsing, diffing, scenario extraction, and traceability, which forms a coherent core workflow. A minor gap is the lack of tools for updating or generating requirements, but this is not a severe omission for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Entalpa Requirements MCPOAuth
com.entalpa
Live Entalpa requirements, stories, stakeholders, interfaces, and project traceability.
Product Management Project Management
1
3TG Test Generation A
dev.3tg
3rd Generation Testing (3TG) — generate deterministic test suites from Markdown spec tables via MCP.
Testing & QA Tools Developer Tools
102
dot•requirements AOAuth
io.dotrequirements
Write product documentation to share with your whole team, including testable specifications.
Developer Tools Documentation Access Software Architecture
201
SpecProof A
ai.specproof
SpecProof: Search standards specs with MCP-ready precision.
Search Documentation Access Developer Tools
172

Related MCP Servers

eazy-ba
Product Management Developer Tools Project Management
God1n
A
license
B
quality
D
maintenance
Captures and organizes requirements as markdown, tracks relationships between personas, requirements, use cases, and user stories.
Updated 3 months ago (2026-07-01 10:58 UTC)
12
6 npm
MIT
IEC 62304 Requirements MCP
Legal & Compliance Documentation Access
Pakawat-Dev
F
license
A
quality
D
maintenance
Enables management of software requirements in compliance with IEC 62304 Class C medical device standards, including requirement creation, versioning, traceability matrix generation, and risk control integration.
Updated 10 months ago (2025-11-15 14:19 UTC)
10
1
-
AIQUAA Playwright MCP Server
stevenayal
A
license
Not graded
quality
A
maintenance
Converts requirements into traceable, CI-ready Playwright BDD tests connected to business rules, with support for Gherkin generation, rule mapping, and automated test pipelines.
Updated 12 days ago (2026-09-11 10:47 UTC)
7 npm
MIT
Requirement Trace Checker
Testing & QA Tools Project Management
YanKe1816
F
license
Not graded
quality
C
maintenance
Enables users to analyze project materials and build traceability from requirements to coverage, identifying gaps.
Updated 2 months ago (2026-07-26 12:24 UTC)
-