SpecGuard MCP server has 4 tools with clear governance-domain naming (specguard_*). All tools have descriptions (avg 120 chars, within baseline 34-392 range) and documented input schemas with type definitions. However, schemas lack depth: parameters have types but minimal constraint documentation (no enums, ranges, or format specs). Output schemas are not documented, LLMs cannot predict return structure. Error handling is absent from visible code; no recovery guidance or actionable error messages. Tool composition is sound (each does one thing), but descriptions could be more prescriptive about when to call each tool vs. alternatives.

• Document output schemas for all 4 tools. Example: 'Returns {verdict: string ("allowed"|"blocked"), reason: string, advisory: boolean}'. This enables LLMs to chain tools and extract the right fields.
• Add enum constraints to 'change_class' parameter: declare as enum with values ["edit", "scope-change"]. Replace free-form string with formal constraint.
• Enhance parameter descriptions with format/range hints. E.g., 'identity: User identifier (email, username, or UUID). Example format: [email protected] or john.doe).'
• Add error handling and recovery guidance. E.g., 'If governance not found, call specguard_list_watched_paths() to verify the file is governed. If not, the tool will return advisory=true.'
• Clarify tool selection logic in descriptions. E.g., 'Use specguard_check_permission to verify role-based access; use specguard_check_proposed_change to evaluate content against governance rules.'