The lore server defines 7 tools with basic schemas and descriptions, but falls short of production quality. All tools have input schemas with type definitions and descriptions present, meeting minimum requirements. However, descriptions are terse (10-50 chars), parameter descriptions lack actionable detail, and output schemas are not documented. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. Error handling and recovery guidance are absent. Tool naming follows verb_noun convention (review_*, pull_*) but lacks clarity on state transitions and prerequisites.

• Expand tool descriptions to 100-200 characters. Include WHAT the tool does, WHEN to call it, and WHAT it returns. E.g., 'review_poll: Check for findings and status updates on an open code review. Call this after review_start to monitor progress. Returns findings array, status (pending|in_progress|complete), and next_poll_delay_ms.'
• Document output schemas for all tools. Specify return type (object/array), required fields, and field types. E.g., review_poll returns {findings: [{id, severity, file, line, message}], status: string, complete: boolean}.
• Add tool annotations: mark review_start, review_submit, review_attest, pull_fresh with destructiveHint=true; mark review_poll, review_inbox with readOnlyHint=true; mark review_cancel with destructiveHint=true.
• Add parameter constraints: repo and branch as regex patterns (e.g., '^[a-zA-Z0-9._-]+$'); diff as 'unified diff format (RFC 3881)'; review_id as UUID or opaque string format.
• Add error handling guidance to each tool: document common failure modes (not found, permission denied, timeout), classify as retryable/user-fixable/fatal, and suggest recovery steps (e.g., 'If review not found, call review_inbox to list open reviews').