The server provides 9 tools with consistently strong descriptions and well-structured schemas. All tools have clear, contextual descriptions (range 150-300 chars), proper JSON Schema definitions with typed parameters, and logical naming conventions. The primary weaknesses are: (1) lack of output schema documentation, tools return results but response structures are not formally defined; (2) no error handling guidance in descriptions; (3) missing idempotency/destructiveness annotations; (4) parameter descriptions could provide more specific guidance on usage patterns and prerequisites. Tool naming is verb-noun consistent (get_*, search_*, list_*) and descriptions clearly explain WHAT each tool does and WHEN to use it. All parameters are properly typed with enums where appropriate (e.g., is_mutagenic, is_genotoxic, is_carcinogenic in list_substances_by_class_and_safety). All tools are READ_ONLY, reducing risk, but this is not explicitly declared in tool definitions.

• Document output schemas for all tools in the tool registration. Use FastMCP's response model or add a 'response_schema' field describing fields, types, and nesting. Example: get_risk_assessments should return {hazard_id: int, population: str, assessment_type: str, risk_value: float|null, ...}.
• Add error handling guidance to tool descriptions. Example: 'If no results found, the substance may not exist in OpenFoodTox. Try search_substance() with a partial name or E-number.' or 'If HAZARD_ID is invalid, verify using get_risk_assessments() with the SUB_COM_ID first.'
• Apply tool annotations via @mcp.tool(readOnly=true, idempotent=true) for all tools. This makes safety properties machine-readable and reduces LLM guessing.
• Expand parameter descriptions with discovery hints. Example: 'sub_class: Optional filter for substance class (e.g. "Food additives", "Pesticides"). Call search_substance() first to see available classes, or use partial matches for common keywords.'
• Rename list_hazard_ids_by_assessment to list_hazard_ids_by_risk_assessment to clearly distinguish from list_substances_by_assessment.
• Document pagination strategy explicitly. For list_* tools, state: 'Returns up to [limit] results (default 10, max 100). To retrieve all results, implement client-side pagination by calling again with offset=[last_returned_count].' Include 'total_count' and 'has_more' fields in response.
• For tools requiring IDs (get_risk_assessments, get_toxicity_endpoints, etc.), add a note: 'To find HAZARD_ID/TOX_ID/etc., use search_substance() or list_substances_by_assessment() first.' This guides multi-step workflows.

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

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