Pursers defines 25 tools with consistent naming (verb_noun pattern) and basic descriptions. All tools have input schemas with typed parameters and descriptions. However, descriptions are terse (avg ~40 chars, well below the 194-char baseline), lack context on WHEN to use each tool, and omit recovery guidance. Output schemas are not documented. Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Tool composition is sound (single responsibility, clear chains), but parameter constraints are minimal (few enums, no ranges). Security posture is unclear, no audit logging visible, no permission gates documented.

• Expand tool descriptions to 100 - 200 chars. Include WHEN to use the tool, how it differs from similar tools, and any prerequisites. E.g., 'Get current board state snapshot with all tickets and agents. Call this first to see available work before claiming a ticket. Returns ticket IDs for use with ticket_get or ticket_claim.'
• Document output schemas for all tools. Specify what fields are returned, their types, and which IDs/references are included for chaining. E.g., board_snapshot should document that it returns ticket_id, agent_name, and status fields.
• Add formal enum constraints to parameters with fixed options (priority, role, verdict, memory_type, wait_for). Use JSON Schema enum arrays instead of relying on description text.
• Add numeric ranges to parameters: max_bytes (1 - 1000000), limit (1 - 100), depth (0 - 10), timeout_s (1 - 3600). Include these in both the schema and description.
• Implement error handling with recovery guidance. E.g., ticket_claim should return 'Ticket already claimed by <agent_name>. Try ticket_list(status=open) to find unclaimed work.' instead of a bare error code.