Four tools with complete input schemas and descriptions. Naming follows verb_noun pattern (verify_, compare_, import_, render_). Descriptions are clear and security-conscious (e.g., 'Never imports cookies, sessions, provider prompts, or executable instructions'). All parameters have type constraints and descriptions. However, output schemas are not documented in the source code provided, and error handling guidance is absent. Tool descriptions average ~120 chars (within baseline 194 chars), but lack explicit guidance on when to use each tool vs. alternatives. No parameter descriptions explain expected formats or constraints beyond type/enum.

• Document output schemas for all four tools. Example: 'Returns {success: boolean, receipt: DecisionReceipt, errors: string[]}' so LLMs know what fields to expect.
• Add error handling guidance to tool descriptions. E.g., 'If path is invalid, returns {success: false, error: "Path not found", suggestion: "Check DECISION_RECEIPT_ROOT environment variable"}.'
• Expand parameter descriptions with format constraints. E.g., 'path: Relative path from DECISION_RECEIPT_ROOT (e.g., "2024-01-15/decision-abc"). Must not contain ".." or symlinks.'
• Clarify tool selection criteria. E.g., 'Use verify_receipt to check integrity; use render_receipt to display contents; use compare_receipts to see what changed between two versions.'
• Document the 'force' parameter behavior in import_result. E.g., 'If output_path already exists, force=true overwrites it; force=false returns an error with the existing receipt details.'