Two tools with complete input schemas and descriptions, but significant gaps in output documentation and error handling. Tool names follow verb_noun convention (search_, get_). Descriptions are adequate (150-200 chars) but lack actionable guidance on when to use each tool vs. the other, and do not document output structure. Parameters have types and descriptions, but lack constraints (enums, ranges, patterns). No error handling guidance visible. No tool annotations (readOnlyHint, etc.). Output schemas are undocumented, LLMs cannot plan downstream calls or extract structured data reliably.

• Document output schemas for both tools. Example for search_companies: 'Returns {totalResults: number, companies: [{businessId, names: [{value, type, languageCode}], mainBusinessLine, companyForms: [{code, descriptions}], addresses: [{street, city, country}], status}]}'. This enables LLMs to extract and chain data.
• Add enum constraints to companyForm and mainBusinessLine parameters. E.g. companyForm: enum ['16', '17', '18', ...] with descriptions ('16'='Oy', '17'='Oyj'). Replace free-form strings with machine-parseable options.
• Add min/max bounds to numeric parameters. E.g. page: {type: 'number', minimum: 1, description: '1-based page number (default 1, max 100)'}. Prevent LLMs from passing absurd values.
• Enhance error messages with recovery guidance. E.g. if businessId not found, return 'Company not found. Try search_companies() with the company name instead.' If API returns 400, parse and return 'Invalid companyForm code. Valid codes: 16 (Oy), 17 (Oyj), ...'
• Add readOnlyHint annotation to both tools in the tool definition. This signals to agents that these calls are safe to retry and have no side effects, enabling smarter retry logic.