CourtListener MCP has clear, well-structured tool definitions with good naming (verb_noun pattern) and reasonable descriptions (150-200 chars). All three tools have complete input schemas with typed properties and required fields. However, parameter descriptions lack actionable constraints (no enums, ranges, or format guidance), output schemas are not formally documented, and error handling is minimal. The server strips API verbosity well but does not guide LLM recovery on failures. Composition is sound, three focused, single-responsibility tools with clear chaining potential (search → get_opinion).

• Add enum constraints for 'court' parameter. Document valid court codes (scotus, ca1 - ca11, nysd, etc.) as an enum or provide a discovery tool (list_courts) to enumerate valid values.
• Document output schemas explicitly. Add JSDoc or inline comments showing the structure of opinions[], dockets[], and opinion object fields (id, author, date_created, text, url, download_url).
• Enhance error messages with recovery hints. E.g., 'Opinion {id} not found. Try search_opinions(query="...") to find valid opinion IDs.' or 'Invalid court code. Call list_courts() to see available options.'
• Specify date format validation and error handling. Add validation in getOpinion/searchOpinions to reject malformed dates and return 'date_after must be YYYY-MM-DD format (e.g., 2024-01-15)'.
• Document result limits and pagination. State in tool descriptions: 'Returns up to 50 results. Use pagination (next_cursor or offset) for additional results.' Add limit/offset parameters if API supports them.