Living Solution Graph MCP defines 21 tools with complete JSON Schema input definitions and descriptions. Naming follows verb_noun convention (get_, set_, claim_, update_, review_, remember_, search_, etc.). Descriptions are present and substantive (avg ~120 chars), explaining WHAT each tool does and WHEN to use it. However, parameter descriptions are largely absent, the schema shows types but not what each parameter controls or its constraints. Output schemas are not documented in the source. Error handling guidance is not visible.

• Add parameter descriptions to all tools. For each parameter, explain what it controls, its valid range, and any constraints. Example: 'recursive (boolean): If true, include all descendant nodes; if false, only direct children.' This enables LLMs to construct valid calls without guessing.
• Document output schemas for all tools. Specify what fields are returned, their types, and which fields are safe to pass to downstream tools. Example: 'Returns {work_id, status, owner, claimed_at, deadline}. Pass work_id to update_work() or review_work().'
• Add error handling guidance to tool descriptions. State what errors can occur and what the LLM should do. Example: 'If work_id not found, call claim_next_work() to get a valid work_id. If version mismatch, reload context with get_work_context().'
• Implement confirmation or dry-run for destructive operations. Add a 'confirm' parameter to memory.forget_project and solution.update_work (release action) that defaults to false. Require explicit confirm=true to proceed, preventing accidental data loss.
• Refactor tool registration to be explicit rather than inferred. Replace the factory function with direct tool definitions so tool schemas are statically verifiable and easier to audit.