manifestation-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| healthA | Liveness check. Returns the server name and version. |
| start_projectA | Begin a design-first project. Creates state and returns the first interview questions. Ask the user these; do NOT write code yet. |
| submit_answersA | Submit the user's answers to the current discovery questions. Returns either more questions or advances the project to the SPEC phase. |
| next_spec_chunkA | Get the next spec chunk to show the user for sign-off (drafts the spec on first call). |
| review_spec_chunkA | Approve or revise the current spec chunk. 'approve' advances; 'revise' redrafts with feedback. |
| make_planA | Generate the bite-sized red/green TDD plan (repo-aware). Returns the full task bodies for the user to review. Does NOT start execution — call approve_plan after the user signs off. |
| approve_planA | Record the user's approval of the generated plan and advance to EXECUTE. |
| runA | Run the subagent-driven execution loop: implementer -> server-verified TDD gate -> reviewer, per task. 'until' stops after N tasks; 'max_agent_calls' and 'max_budget_usd' cap spend. Requires an approved plan. Long-running; streams progress; checkpoints per step. |
| reset_taskA | Reset a BLOCKED (or any) task back to pending so run can retry it. |
| statusC | Report a project's current phase and task progress. |
| list_projectsA | List all known Manifestation projects. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| manifestation | Kick off a design-first Manifestation project from a one-line brief. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| skills | All bundled Manifestation skills (TDD, YAGNI, DRY, ...). |
TDQS
Scored across 11 tools
Each tool maps to a distinct phase or concern: liveness, discovery Q&A, spec chunk retrieval/review, plan generation/approval, execution, task reset, status, and project listing. Pairings like make_plan/approve_plan and next_spec_chunk/review_spec_chunk are sequential rather than overlapping, and the descriptions reinforce their roles.
Most tools follow a verb_noun pattern (start_project, submit_answers, approve_plan, reset_task, list_projects), but health, status, run, and next_spec_chunk deviate by using bare nouns, a bare verb, or a noun-phrase without an action verb. The overall style is still readable and mostly predictable.
11 tools fit the server's staged workflow—discovery, spec, plan, execute, and observe—and each serves a clear purpose. There is no obvious bloat; even the health and list_projects tools are reasonable utility surfaces.
The core lifecycle is well covered: start_project, submit_answers, next_spec_chunk, review_spec_chunk, make_plan, approve_plan, run, reset_task, and status form a coherent path with no dead ends. Minor gaps exist, such as no explicit cancel/stop for a running execution or a revision path for an already-approved plan/spec, but these can likely be worked around.