Server has 9 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (lookup_cnpj, list_filiais, search_companies). Descriptions are adequate (100-200 chars) but lack LLM-optimized guidance on when to use each tool vs. alternatives. Parameters have types and descriptions, but lack constraints (enums, ranges, patterns). Output schemas are not documented, LLMs cannot predict response structure for chaining. No error handling guidance visible. All tools are READ_ONLY, reducing risk, but composition could be tighter (e.g., lookup_cnpj returns establishments; list_filiais duplicates that capability).

• Document output schemas for all tools. For lookup_cnpj, specify: {razao_social: string, capital_social: number, natureza_juridica: string, simples: boolean, socios: array, estabelecimentos: [{situacao_cadastral: string, endereco: object, cnaes: array}]}. This enables LLM chaining.
• Add JSON Schema constraints: search_companies.query minLength=3, per_page maximum=20; companies_by_owner.limit maximum=100; companies_at_same_address.cep pattern='^\d{8}$'. Replace text-only constraints.
• Enhance descriptions with recovery guidance. E.g., 'If lookup_cnpj returns 404, try search_companies() with partial name or CNPJ digits.' Add to each tool's description.
• Clarify tool selection. Add to companies_by_owner: 'Use this to find all companies where a person is a partner. For companies at a location, use companies_at_same_address instead.' Similar hints for contact-based search.
• Consider consolidating lookup_cnpj + list_filiais. If lookup already returns filiais, list_filiais may be redundant. If list_filiais offers filtering (by UF) that lookup doesn't, document this distinction clearly.