A Model Context Protocol server for software development planning with sequential thinking and todo management
This server has 6 tools with explicit schemas and descriptions visible in src/index.ts. However, critical gaps exist: (1) Parameter descriptions are minimal or absent for many inputs. (2) Output schemas are not documented anywhere, callers cannot predict response structure. (3) Error handling provides no recovery guidance. (4) Tool composition issues: stateful server design with 'currentGoal' requires multi-call workflows. (5) STDIO transport caps overall server score. The tools are domain-appropriate (planning, todo management) but definitions lack the rigor needed for production LLM agents. Most tools fall into the 45-55 range individually; averaging to ~52 overall.
Add a new todo item to the current plan
Get all todos in the current plan
Remove a todo item from the current plan
Save the current implementation plan
Start a new planning session with a goal
Update the completion status of a todo item
No output schemas documented anywhere. LLMs cannot infer response structure, field names, or types. This forces agents to retry/inspect responses blind, wasting tokens and inviting hallucination.
Stateful server design: currentGoal is stored as private state, requiring agents to call start_planning first, then subsequent tools. This breaks idempotency and forces multi-call workflows. Best practice: pass goal_id or plan_id as parameters to each tool so agents can call tools independently.
No error recovery guidance. Tools have no documented error cases or what the agent should do on failure. E.g., remove_todo does not document what happens if todoId is invalid, should the agent retry, ask the user, or call get_todos to discover valid IDs?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
get_todos output is unconstrained. Description says 'Get all todos' but does not specify pagination, limits, or sorting. Returning thousands of todos will blow context windows. Should cap results at 20-50 and document the limit.
Parameter 'codeExample' in add_todo is optional but has no description explaining when or why to include it. This invites LLM confusion, is it a code snippet? A link? A template?
Tool descriptions are all under 50 characters. While present, they lack sufficient detail to guide LLM selection vs. similar tools. Baseline expectation: 50-200 chars to explain what, when, and why.
No tool composition support. save_plan takes a 'plan' string parameter, but it is unclear what format the plan should be (markdown? JSON? free text?). add_todo does not reference save_plan, and save_plan does not reference the list of todos. Chaining is implicit and error-prone.