Five tools with complete schemas, descriptions, and parameter types. All tools are READ_ONLY with proper annotations. Descriptions are clear and action-oriented (avg ~120 chars). Parameters have types and descriptions. However, descriptions lack dependency hints and recovery guidance. Output schemas are not explicitly documented in the source. Error handling is minimal, no guidance on what to do if a search returns no results or if an API call fails. Tool composition is sound: search→fetch chain is idiomatic. Naming follows verb_noun convention (search, fetch, list, get). No critical gaps, but lacks the polish of A-grade tools.

• Document output schemas for all five tools. Include field names, types, and descriptions. Example: 'Returns array of {code: string, name: string, theme: string, data_available: boolean}'.
• Add error recovery hints to descriptions. E.g., 'If no indicators match, try broader keywords or check available themes with uis_list_geo_units.'
• Rename 'search' → 'search_uis_documents' and 'fetch' → 'fetch_uis_document' to avoid ambiguity with other search/fetch tools in multi-tool environments.
• Specify array constraints in 'uis_get_data': max 50 indicators, max 50 geo_units, year range 1970 - 2024. Add enum for 'provenance_mode': ['minimal', 'detailed'].
• Document pagination behavior: 'Returns up to `limit` results. If more exist, use `offset` to fetch next page. Response includes `total_count` to enable LLM-driven iteration.'

Inferred effective spec: 2026-07-28+.

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