Three well-named tools with clear, actionable descriptions (150 - 200 chars each). All tools have complete input schemas with proper types and required fields. search_lei includes enum constraints for status; get_lei and get_lei_relationships accept LEI codes with clear descriptions. Output normalization is visible (normalizeRecord function), returning structured objects with typed fields. However, output schemas are not formally documented in the tool definitions, LLMs must infer response structure from descriptions. Error handling is basic (404 → 'not found', other errors → status + truncated body); no recovery guidance or actionable error messages. No parameter validation rules stated (e.g., LEI format, page_size bounds). Missing tool annotations (readOnlyHint, idempotentHint) despite all three being read-only operations.

• Add formal output schema definitions to each tool. Document the structure of normalizeRecord() return value (lei, legal_name, jurisdiction, category, legal_form, entity_status, registration_status, addresses, bic, isins, gleif_url) with types and descriptions.
• Enhance error messages with recovery guidance. E.g., if get_lei(lei) returns 404, respond: 'LEI not found. Try search_lei() with the legal entity name to find the correct LEI code.'
• Add readOnlyHint: true to all three tools in the schema to signal they are safe to retry and do not mutate state.
• Document parameter constraints explicitly. For search_lei: 'page_size must be 1 - 200 (default 25)'. For get_lei: 'lei must be a 20-character alphanumeric code (ISO 17442 format)'.
• Clarify pagination for search_lei. Document that results are limited to page_size items; if total > page_size, explain how to fetch additional pages (e.g., via offset or next_cursor if GLEIF API supports it).