spec-loop
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPEC_LOOP_ROOT | No | The project root in which the server looks for `spec/`. Used when no `root` argument is passed to a tool call. Falls back to `CLAUDE_PROJECT_DIR` (set by Claude Code), then to the server's working directory. A value still holding an unexpanded `${…}` is skipped. | |
| CLAUDE_PROJECT_DIR | No | Project directory set by Claude Code, used as a fallback for locating `spec/` when no `root` argument and no `SPEC_LOOP_ROOT` are provided. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| learnA | Return one topic of the spec-loop method; phases and fields are generated from the schema. Topics: artifacts, feedback, fields, glossary, index, loop, phases, project, questioning, use-cases. |
| featuresB | One summary line per spec-loop feature under spec/: id, name, phase, completeness, pending owner edits or alterations, last modification; echoes the resolved root and spec path. |
| statusC | Phase, completeness (recomputed by validate), pending owner edits and alterations (recomputed by diff against the manifest), last reconciliation and phase history of one spec-loop feature. |
| createA | Write the skeleton of a new spec-loop feature (next FEAT number, first phase), render it and refresh spec/README.md. One feature at a time: refuses while another feature is not done, naming it, unless the owner asked for it explicitly (by owner with a reason, recorded in the new feature's lifecycle). |
| validateA | Validate a spec-loop feature.json, or a candidate object, against the schema and the coverage checks of its phase, and parse every Mermaid artifact; for a stored feature, also check that every svg artifact file exists and is a safe svg. Every error has a JSON pointer. |
| renderA | Project a spec-loop feature.json into its rendered/ folder (deterministic) and refresh the manifest and spec/README.md. Refuses while owner edits are unverified. |
| diffA | Compare the regenerated projection of a spec-loop feature with the files on disk and the manifest; each hunk carries its block id and JSON pointer, and every alteration is classified. |
| patchA | Apply an RFC 6902 JSON Patch to a spec-loop feature.json, validate, write only when no invalid error remains, then re-render. id, name, phase and lifecycle are not patchable. |
| phaseA | Move a spec-loop feature to the next phase of the schema, only when the current phase is complete (entry rules of the next phase included), no owner edit is pending and every beforeLeave project hook of spec/spec-loop.json exits 0; or, with to, back to an earlier phase on the owner's decision with a reason. Runs the onEnter project hooks of the phase entered, records the history entry and every hook run. |
| reconcileA | Close a reconciliation of the owner edits of a spec-loop feature: apply the JSON Patch for the coherent owner edits, turn each reported one into an open question, restore the projection exactly (owner files kept in .spec-loop/overwritten//) and record lastVerify. applied + reported must equal the pending count from diff. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
The tools mostly target distinct lifecycle operations: listing features, inspecting one feature, creating, validating, rendering, patching, phase transitions, diffing, reconciling, and reading method topics. There is some conceptual overlap between diff/status/features because status and features summarize information that diff computes, but the boundaries are clear enough for an agent.
All tool names are lowercase single tokens with no mixed casing or chaotic style. They are not a strict verb_noun pattern and mix verbs with nouns such as features, status, and phase, but the convention is still predictable and readable.
Ten tools is well scoped for a spec-loop feature lifecycle server. Each tool covers a distinct operation in the create-validate-render-diff-patch-phase-reconcile workflow, and none appears redundant.
The surface covers the core lifecycle: create, inspect, validate, render, patch, transition, diff owner edits, reconcile, and learn the method. Minor gaps exist around deleting or archiving features and explicitly managing open questions generated during reconciliation, but agents can work around these.