Montana Food Code server has 4 tools with clear action verbs (list_, classify_, lookup_, search_) and reasonable descriptions (100-200 chars). However, critical gaps undermine production readiness: (1) All tools lack explicit input schemas in the visible code, parameters are documented in docstrings but not registered as JSON Schema objects with type/description pairs. (2) Output schemas are completely undocumented, callers cannot predict response structure. (3) Error handling is minimal; tools return free-text strings rather than structured errors with recovery guidance. (4) No pagination support despite search_regulations claiming 'up to 5 results', no limit/offset params. (5) Parameter descriptions exist but lack format constraints (e.g., code format '3-501.16' is mentioned in description but not enforced). Naming is solid (verb_noun pattern), but schema and output documentation are missing entirely.

• Add explicit JSON Schema to each tool's input definition. Use FastMCP's schema parameter to register type, description, and constraints for 'code' (pattern: '^\d-\d{3}(\.\d{2})?$'), 'query' (minLength: 1, maxLength: 200), and 'description' (optional, maxLength: 500).
• Document output schemas. E.g., classify_violation returns {code: string, section: string, category: string, chapter: string, risk_level: string, description: string}. Use structured JSON responses instead of free-text strings.
• Implement structured error responses. Return {error: string, code: 'NOT_FOUND'|'INVALID_INPUT'|'SERVICE_UNAVAILABLE', recovery: string} so LLMs know whether to retry, ask user, or try alternative tools.
• Add pagination to search_regulations: accept 'limit' (1-50, default 20) and 'offset' (default 0) parameters. Return {results: [...], total: number, offset: number, limit: number}.
• Validate 'code' parameter format server-side. Return actionable error: 'Invalid code format. Expected X-XXX or X-XXX.XX (e.g., 3-501.16). Got: "abc".' This enables LLM self-correction.