GSD MCP server has critical definition gaps. All 9 tools lack parameter descriptions entirely, the rubric requires every parameter to have a description explaining what it controls. Most tools have minimal descriptions (10-30 chars), below the 50-200 char baseline for LLM-optimized tools. Input schemas are present but sparse: only 3 of 9 tools have any parameters defined, and those lack type information beyond 'string'. No output schemas are documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. The server appears to be a state-machine wrapper around a local STATE.md file, but this domain purpose is not reflected in tool descriptions. No tool composition guidance or chaining IDs documented.

• Expand all tool descriptions to 80-150 chars. Include WHAT the tool does, WHEN to use it, and WHAT it returns. Example: 'gsd_plan_status' → 'Retrieve the current plan execution state from STATE.md, including phase number, plan counter, active blockers, and recent decisions. Call this first to understand the current workflow state.'
• Add descriptions to all parameters. For 'phase', specify: 'Phase identifier as a two-digit string (e.g., "01", "02"). Must match an existing phase directory.' For 'summary' and 'text', clarify length limits and content constraints.
• Document output schemas for all tools. Define what fields each tool returns. E.g., gsd_plan_status returns {phase: string, counter: number, blockers: string[], decisions: string[]}.
• Add error handling guidance. For write tools (gsd_commit_docs, gsd_advance_plan), document: 'Returns error if git commit fails (e.g., no changes staged, merge conflict). Retry after resolving the conflict or staging additional files.'
• Add parameter constraints via enums and patterns. For 'phase', use enum: ['01', '02', '03', ...] or pattern: '^\d{2}$'. For 'message', specify max length (e.g., 200 chars) and character restrictions.