Two tools with minimal schema documentation and descriptions that lack LLM-optimization guidance. verify_article has a single string parameter with no type validation, format constraints, or error recovery hints. list_acts has no parameters but both tools lack structured output schemas. Descriptions are present but generic, they explain WHAT without guiding WHEN to use or HOW to handle failures. No parameter validation rules, no enum constraints, no pagination support despite potential for large result sets. Error handling returns raw exception names without recovery guidance.

• Add JSON Schema with enum constraint to verify_article's citation parameter. Define valid formats: 'art. N [ust. M] CODE' with regex pattern and examples of valid codes (KC, KP, RODO, etc.).
• Document output schemas as structured JSON objects. verify_article should return {article_number, section, text, source_url, act_code, act_name, last_updated}. list_acts should return {acts: [{code, name, jurisdiction, year}]}.
• Implement error categorization. Return {error: string, type: 'not_found'|'invalid_format'|'service_unavailable', recovery: string} so LLM knows whether to retry, ask user, or call list_acts().
• Enhance descriptions with explicit WHEN/WHY guidance. E.g., 'Use verify_article to check exact wording of a cited law before relying on it in legal reasoning. Prevents hallucination by fetching from official sources (api.sejm.gov.pl, EUR-Lex).'
• Add parameter description to citation: 'Citation in format "art. N [ust. M] CODE" where CODE is from list_acts(). Examples: "art. 45 u.k.k.", "art. 28 ust. 3 RODO". Invalid format returns error with valid codes.'

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

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