Four tools with complete input schemas and clear descriptions. Naming follows verb_noun pattern (list_, find_, get_, diff_). Descriptions are substantive (100-200 chars), explaining WHAT and WHEN. All parameters have types and descriptions. However, output schemas are not documented, LLMs cannot predict response structure for chaining. Date validation is rigorous but error messages are generic. No tool annotations (readOnlyHint, idempotentHint). Missing parameter interdependency documentation (e.g., get_revision_text requires either revisionId OR lawUrl, but this is not explicitly stated as mutually exclusive).

• Document output schemas for all four tools. Include field names, types, and whether results are paginated. Example: 'Returns {updates: [{lawId, lawName, amendmentName, revisionId}], total: number}'.
• Add explicit constraint documentation to get_revision_text: 'Either revisionId or lawUrl is required, but not both. If both are provided, revisionId takes precedence.'
• Add tool annotations to the tool definitions: set readOnlyHint=true and idempotentHint=true for all four tools so LLMs know they are safe to retry.
• Improve error messages to include the invalid value and constraint. Example: 'Invalid date: got "2025-01-15", must be 2020-11-24 or later and not a future date.'
• Clarify pagination in list_updates and find_revisions descriptions: 'Results are limited by the limit parameter (default 50/100). If more results exist, call again with an offset or cursor parameter.' (if supported) or 'Results are capped at the limit; no pagination available.'