Three tools with clear verb-noun naming (get_indicators, get_data, list_countries) and reasonable descriptions (120 - 180 chars). All tools have input schemas with type declarations. However, parameter descriptions lack specificity: 'Optional search keyword' and 'ISO 3-letter country code' are vague about constraints, formats, and error cases. Output schemas are not documented, LLMs cannot predict response structure. No error handling guidance. get_data has 3 parameters but only 1 is required; optional params lack defaults or guidance on mutual exclusivity. Descriptions include example values (e.g., 'WHOSIS_000001', 'USA', '2020'), which LLMs may reuse literally. No pagination or result-limiting guidance despite API returning potentially large datasets.

• Document output schemas for all three tools. Specify field names, types, and meaning. Example: 'Returns {total: number, indicators: [{code: string, name: string}]}'. This enables LLMs to plan downstream calls.
• Replace example values with formal constraints. Change 'ISO 3-letter country code (e.g., "USA", "GBR", "JPN")' to 'ISO 3-letter country code (uppercase, e.g. USA). Call list_countries() to discover valid codes.' Add an enum or pattern constraint in the schema.
• Add error handling and recovery guidance. Wrap API calls in try-catch; return structured errors like '{error: "invalid_indicator", message: "Indicator WHOSIS_999999 not found. Call get_indicators() to find valid codes.", retryable: false}'.
• Document result limits and pagination. Update descriptions: 'Returns up to 50 indicators. For more results, use the query parameter to narrow your search.' Add offset/limit parameters if the API supports them.
• Clarify parameter constraints in descriptions. For 'year', specify format: 'Year as YYYY string (e.g., "2020"). Omit to return all years.' For 'country', add: 'Case-sensitive ISO 3-letter code. Call list_countries() to discover valid codes.'