Server has 7 tools with consistent naming (verb_noun pattern: get*) and basic schemas using Zod. All tools are READ_ONLY and well-scoped. However, descriptions are minimal (10-50 chars, well below the 194-char baseline), parameter descriptions are missing entirely, and output schemas are undocumented. Tools return raw JSON without field documentation. No error handling guidance, no pagination metadata in responses, and no field-level descriptions for parameters. Naming is clear but descriptions lack the LLM-optimization guidance required for reliable tool selection.

• Expand all tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs. similar tools), and what structure it returns. E.g., 'Get detailed company profile including registration date, status, and address. Use this for company overview; call getCompanyOfficers for leadership info.'
• Add descriptions to every parameter. E.g., 'companyNumber: The 8-digit Companies House registration number (e.g., 12345678). Obtain via getCompanies() search.' This helps LLMs understand format and how to obtain values.
• Document output schemas explicitly. Create TypeScript interfaces or JSON Schema for each tool's response and include field descriptions in tool docstrings. E.g., 'Returns { companyNumber, companyName, registrationDate, status, address: { street, city, postcode } }'.
• Add pagination metadata to responses. Include totalResults and hasMore flags so LLMs know when to fetch additional pages. E.g., 'Returns { officers: [...], pageIndex, pageSize, totalResults, hasMore }'.
• Wrap API errors with actionable guidance. Catch API errors and return structured messages like 'Company not found. Try getCompanies("company name") to search first.' This enables LLM self-correction.