MCP tools
This page lists each tool of Speccy’s MCP server. speccy mcp runs the server over stdio as the local user. In hosted mode the same tools are at /mcp, with a personal API token. Hand a spec to a coding agent shows the setup.
get_bundle
Section titled “get_bundle”Get one bundle: its files, its verdict, and the text of its spec doc.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
get_findings
Section titled “get_findings”Get the findings of a bundle’s current verdict, MUST first. Each has a message, a suggested fix, and the text it points at.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
level |
string | only findings at this level: MUST, SHOULD, or INFO |
get_tour
Section titled “get_tour”Get the points of a bundle that need a human decision, in order.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
get_traceability
Section titled “get_traceability”Get a bundle’s links, trace ID coverage, and suggested trace IDs.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
get_verdict
Section titled “get_verdict”Get the current verdict of a bundle.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
handoff_bundle
Section titled “handoff_bundle”Take the build packet of a Build Ready bundle: its spec doc, its assets, the spec doc of each bundle it links to, its trace IDs, the build questions with the answer independent readers agreed on, and a re-entry prompt to build from. Speccy records which version you took.
| Input | Type | Required | Meaning |
|---|---|---|---|
acknowledged |
boolean | take the packet although the bundle is not Build Ready, or its verdict is stale | |
bundle |
string | yes | the bundle’s slug or ID |
label |
string | what you call this work: a repo, a branch, or a ticket |
list_bundles
Section titled “list_bundles”List the bundles with their verdicts.
It takes no input.
list_threads
Section titled “list_threads”List the discussion threads of a bundle.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
post_message
Section titled “post_message”Post a message to a thread, or open a thread on a bundle when no thread_id is given.
| Input | Type | Required | Meaning |
|---|---|---|---|
body |
string | yes | the message |
bundle |
string | with no thread_id: the bundle to open a new thread on, by slug or ID | |
thread_id |
string | the thread to post to | |
title |
string | with no thread_id: the title of the new thread |
report_build
Section titled “report_build”Report what you learned about the doc while you built from a build packet. kind blocked means you cannot build the section without an answer, and it opens a blocking thread. kind note means you built something and the doc was unclear. Name the section or the trace ID, so the question lands on that text.
| Input | Type | Required | Meaning |
|---|---|---|---|
handoff |
string | yes | the handoff ID from the build packet |
kind |
string | yes | blocked or note |
section |
null or array | the heading path of the section the report is about | |
text |
string | yes | what you need, in your own words |
trace_id |
string | a trace ID the report is about, such as REQ-012 |
review_bundle
Section titled “review_bundle”Run a review of a saved bundle and wait for the verdict. The model stages can take minutes.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
stages |
null or array | the model stages to run: rubric, grounding, divergence, coherence. Absent means all. |
review_content
Section titled “review_content”Review markdown files that are not saved: a spec doc with a type in its frontmatter, and its assets. No bundle changes; the server keeps the result for its report for 90 days.
| Input | Type | Required | Meaning |
|---|---|---|---|
files |
null or array | yes | the spec doc and its assets |
main_doc |
string | the spec doc of a single-file bundle, when its frontmatter has no type | |
profile |
string | the profile for a spec doc with no type, such as prd or sdd | |
slug |
string | the bundle’s slug, so links to and from other bundles resolve | |
stages |
null or array | the model stages to run: rubric, grounding, divergence, coherence. Absent means all. |
verify_build
Section titled “verify_build”Verify one build against the bundle. Paste the URL of the repo, branch, commit or pull request you built, or name a folder; with neither, Speccy reads the repo the doc’s implemented-by link names. Speccy finds where each requirement is implemented and tested, and gives each one an outcome: implemented, untested, unproven, missing or breached. Speccy reads the code; it never runs it and never runs the tests, so a cited test is a citation and not a pass. A missing or breached MUST opens a blocking thread on the bundle. Give a claim for a requirement when you know where it lives; leave the claims out and Speccy finds them.
| Input | Type | Required | Meaning |
|---|---|---|---|
bundle |
string | yes | the bundle’s slug or ID |
claims |
null or array | where each requirement lives, when you know. A claim replaces what Speccy would find for that requirement, and every target in it must hold. | |
handoff |
string | the handoff ID from the build packet | |
path |
string | a folder on disk, instead of a repo and a commit | |
repo |
string | the repo you built, as owner/name | |
sha |
string | the commit you built | |
target |
string | the GitHub URL of the repo, branch, commit or pull request you built, or an absolute folder path in local mode. Leave it and repo out to verify the repo that the doc’s implemented-by link names |