ODIN Sentinel exhibits severe definition quality gaps across all 50 tools. While tool names follow verb_noun convention (get_, validate_, evaluate_, compute_, etc.), descriptions are uniformly generic and fail to distinguish tools or guide LLM selection. Input schemas are present but minimal: most parameters lack descriptions entirely, violating the critical rule that every parameter needs a description. Output schemas are completely undocumented. No error handling guidance, no recovery paths, no actionable error messages. The server appears to implement a proprietary 'ODIN' governance protocol with domain-specific concepts (boot receipts, delegation packets, harness probes, govdisp events), but the tool definitions do not explain WHAT these concepts are, WHEN to use each tool, or HOW they relate. An LLM cannot reason about tool selection when descriptions are identical boilerplate ('Retrieve X', 'Validate Y', 'Evaluate Z'). This is a domain-specific tool suite that has been exposed via MCP without proper LLM-facing documentation.

• Rewrite all 50 tool descriptions to follow the pattern: WHAT (one sentence stating what the tool does in domain terms), WHEN (when to use it vs. similar tools), RETURN (what the response contains). Target 50 - 200 characters per description. Example: 'get-role-profile: Retrieve the full profile for a role (permissions, responsibilities, escalation path). Use this before delegating authority to understand role constraints. Returns: role_id, name, permissions[], escalation_contact.'
• Add descriptions to every input parameter. For each parameter, explain: what it represents, valid values or format, how to obtain it if it's an ID. Example: 'roleId: The unique identifier for a role (e.g., "exec-pm", "dev-worker"). Obtain from get-role-card or list-roles. Must be a valid role in the current team.'
• Document output schemas for all tools. For each tool, specify the response structure: field names, types, and meaning. Example: 'get-role-profile returns: {role_id: string, name: string, permissions: string[], escalation_contact: string, created_at: ISO8601}'
• Add error handling guidance to validation and evaluation tools. Specify what validation failure looks like, what the error message contains, and what the LLM should do next. Example: 'validate-boot-receipt returns {valid: boolean, errors: string[]}. If valid=false, errors list the constraint violations. Suggest corrections to the user or call get-boot-receipt-schema to see the expected structure.'
• Create a domain glossary or link to documentation in the server description. Explain key concepts (boot receipt, delegation packet, harness probe, govdisp event, CMUX, slice, sentinel) so LLMs understand the protocol context. Add a note to tool descriptions: 'See ODIN Sentinel protocol documentation for domain context.'