Lauyer provides 7 tools with complete input schemas and descriptions. All tools are READ_ONLY and follow verb_noun naming (dgsi_search, dgsi_fetch, dr_search, etc.). Descriptions are present (avg ~80 chars) but lack depth on WHEN to use each tool or dependencies between them. Parameters have types and descriptions, but lack enums for constrained values (e.g., 'sort' accepts 'relevance or date' as free text, not enum). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance. The health tool is a utility, not a domain tool. Overall: solid foundation, but missing LLM-optimization patterns around output documentation and error guidance.

• Add JSON Schema output schemas to all tools. Document response structure: e.g., dgsi_courts returns array of {alias: string, name: string}; dgsi_search returns {results: [{id, title, date, url}], total: int, next_cursor?: string}.
• Convert 'sort', 'format', 'type', 'content' parameters to JSON Schema enums. Replace 'relevance or date' with enum: ['relevance', 'date']. Replace 'json or md' with enum: ['json', 'md'].
• Add pagination to dgsi_search and dr_search. Include 'offset' or 'page' parameter; document max result limit (e.g., 50 per page); return 'total_count' and 'next_cursor' in response.
• Enhance tool descriptions with dependency hints. E.g., 'Call dgsi_courts first to see available court aliases, then use them in dgsi_search.' This guides multi-step planning.
• Add error recovery guidance. Return structured errors: {error: 'upstream_unavailable', message: 'DGSI server unreachable. Retry in 30s or try dr_search for legislation instead.', retryable: true}.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry