12 tools with consistent naming (verb_noun pattern: get_*, search_*, nhvr_ prefix). All have descriptions (avg 95 chars, within 10-1024 range). Input schemas present with types and descriptions for all parameters. However, output schemas are undocumented, tools return formatted strings (markdown/json) with no structured field definitions. Parameter descriptions are minimal (avg 45 chars) and lack constraint details (e.g., valid enum values for 'scheme', 'breach_type', 'role', 'module', 'permit_type'). No error handling guidance visible. No tool annotations (readOnlyHint, etc.). Composition is sound, each tool has one responsibility. Missing: output schema documentation, parameter constraints as enums, error recovery guidance.

• Document output schemas for all tools. Define structured response objects with typed fields (e.g., {vehicle_registration: string, owner: string, status: string} for search_vehicle_registration). Return JSON by default; offer markdown as a formatting option, not a structural choice.
• Convert parameter constraints to enums in JSON Schema. Define scheme as enum: ['standard', 'bfm', 'afm']; breach_type as enum: ['mass', 'dimension', 'loading', 'fatigue', 'speed']. Add descriptions for each enum value (e.g., 'bfm: Basic Fatigue Management').
• Add error handling guidance to tool descriptions. E.g., 'If vehicle not found, returns error with available search tips. Try search_regulations() for general compliance info.' Include retryable vs. fatal error classification.
• Add readOnlyHint annotation to all tools in FastMCP registration. This signals to clients that these tools are safe to cache and retry without side effects.
• Expand parameter descriptions to 70-100 chars. Explain when to use each parameter and what the output contains. E.g., 'output_format: Return as markdown (human-readable) or json (structured). Use json for downstream tool chaining.'