Server has 6 well-named tools with detailed descriptions and comprehensive parameter schemas. All tools follow verb_noun naming (search_tenders, get_tender, get_customer_history, get_supplier_stats, lookup_okpd2, ping). Descriptions are substantive (100-300+ chars) and explain WHAT, WHEN, and any prerequisites. Parameters are typed with descriptions. However, output schemas are not explicitly documented in the source code, only input schemas are visible. Error handling is minimal (no recovery guidance, no error categorization). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY. Missing structured error responses and per-item success/failure for batch-like operations.

• Document output schemas for all tools. Specify field names, types, and structure. Example: 'Returns {"tenders": [{"reg_number": string, "title": string, "price_rub": number, ...}], "next_page_token": string|null, "total_count": number}'.
• Add tool annotations to FastMCP tool registration. Mark all 6 tools with readOnlyHint=true since they are all READ_ONLY and idempotent. Example: @mcp.tool(readOnlyHint=True, idempotentHint=True).
• Enhance error responses with recovery guidance. Return structured errors: {"error": "invalid_filter", "message": "Invalid law_type: got ['invalid']. Must be one of: ['44-fz', '223-fz', '615-pp']", "retryable": false}.
• Document parameter relationships in get_customer_history and get_supplier_stats. Clarify: 'Either inn or ogrn is required; if both provided, inn takes precedence.' Add validation error if neither is provided.
• For search_tenders, add enum constraints to law_type, status, and platform parameters in the schema (not just description). This enables LLM autocomplete and prevents hallucinated values.

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

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