
Speccheck
io.github.CloudCorpRecordsPublished by GitHub account CloudCorpRecordsv0.1.0Updated Nov 3, 2026
Verify every spec requirement is claimed by an issue, PR, or code reference; list gaps.
Overview
Speccheck's local MCP server; no sign-in required; STDIO.
No AI overview yet: these facts come from the registry entry and the server itself.
Installation
In SourceWeft
- Open Speccheck in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
speccheck
A spec is only as good as the work that actually answers it. Requirements get written, issues get filed, pull requests get merged, code lands — and somewhere in that pile the mapping between "what the spec asked for" and "what claims to have done it" quietly rots. speccheck audits that mapping. You supply the spec's requirements and the claims made against them, and it reports which requirements are covered, which are not, which claims point at requirements that do not exist, and how many claims each requirement collected.
Nothing is fetched. A requirement counts as covered the moment at least one claim names its id; the claiming source can be an issue, a pull request, or a code reference, and duplicate claims each count — three issues claiming the same requirement is a fact worth seeing in the count, not noise to deduplicate. A claim naming an id that no requirement has is dangling: it is echoed back in full, in the order the claims arrived, and it counts nowhere — not toward coverage, not toward any requirement's total. It usually means a renamed requirement or a typo, and either way it is the spec owner's problem to see, not the tool's to guess at.
The verdict compresses the report into one word. If
every requirement is claimed, the spec is
fully_covered. Otherwise the coverage percentage —
covered over total, rounded to the nearest integer —
decides: 80 or above is mostly_covered, 50 or above is
partial, and anything lower is sparse. The counts
always travel with the verdict, so the word never has to
be taken on faith.
Malformed input is a validation error naming the
offending path, with no partial result: requirements
must be a non-empty array of objects each carrying a
non-empty id and text, requirement ids must be
unique (a duplicate is an error naming the id), and
claims must be an array — possibly empty — of objects
each carrying a non-empty requirement_id and
source_ref plus a source_kind of issue, pr, or
code. Unknown extra fields are ignored. The computation
is pure and local: no network, no configuration, and no
repository is read or touched.
CLI
args.json contains the full arguments object:
The result is printed as JSON:
claim_counts carries an entry for every requirement,
including zeros, with keys in the order the requirements
were supplied. Exit codes: 0 on success, 1 on a
runtime error (including an unreadable or invalid input
file, or invalid input), 2 on a usage error.
MCP server
MCP client config:
Tools
-
check_spec_coverage— Verify a spec's requirements are claimed by issues, pull requests, or code, from caller-supplied requirement and claim facts.requirements(array, required, at least 1 item) — the spec's requirements; each item is an object with a non-emptyidandtext, and ids must be uniqueclaims(array, required, may be empty) — claims that an issue, pull request, or code reference addresses a requirement; each item is an object with a non-emptyrequirement_id, asource_kindofissue,pr, orcode, and a non-emptysource_ref
Returns
{covered, uncovered, dangling_claims, claim_counts, coverage_percent, verdict, requirement_count, claim_count}.
Docker
Development
License
MIT — Copyright (c) 2026 Rene Turcios
Source: README.md at commit d55b3cf
Tools
0Version history
1- v0.1.0LatestNov 3, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts