Server has 13 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search_, get_, validate_, check_). Descriptions are substantive (100-300 chars) and include use cases. However, output schemas are not documented in the source code provided, only input schemas are visible. Parameter descriptions are present but some lack format constraints (e.g., 'lei' accepts any string; no validation that it's 20 chars). Error handling is minimal, no recovery guidance or actionable error messages visible. Tool composition is sound (each does one thing), but no pagination support visible for list-returning tools (e.g., company_search returns 'limit' but no 'offset', 'page', or 'next_cursor'). Security: no secrets exposed as parameters (good), but no audit logging or permission gates visible.

• Document output schemas for all 13 tools. Specify field names, types, and whether results are paginated. Example: company_search returns {results: [{lei, name, address, country, ...}], total_count, next_cursor}.
• Add pagination to list-returning tools: accept offset/limit or page/page_size, return total_count and next_cursor. Cap results at 20-50 items per call to prevent context window exhaustion.
• Convert free-form string parameters to enums where applicable: country → enum of ISO 3166-1 alpha-2 codes; industry_code → enum of valid NACE Rev.2 codes; vat_number validation → regex pattern in schema.
• Add error handling guidance to tool descriptions. Example: 'If company not found, try company_search() with a partial name. If LEI is invalid (not 20 chars), validate_lei() first.'
• Implement audit logging for compliance tools (check_sanctions, get_beneficial_owners, search_insolvencies). Log caller identity, timestamp, query, and result count. Required for AML/KYC regulatory compliance.