Three tools with identical parameter structure (single 'krs' string param). All have descriptions present but minimal (10-30 chars), below the 50-200 char LLM-optimized baseline. Input schemas visible and properly typed, but lack validation constraints (no regex pattern, length bounds, or enum). No output schemas documented, LLMs cannot infer response structure. No error handling guidance. Tool names follow verb_noun pattern (get_*) which is correct, but descriptions are too terse to guide LLM selection or explain when to use get_entity vs get_entity_full vs get_board.

• Expand tool descriptions to 80-150 chars each. Example for get_entity: 'Fetch current KRS registry entry (name, address, NIP/REGON, legal status). Use this for quick lookups. For full history, use get_entity_full.'
• Document output schema for each tool. Example: 'Returns {nazwa, nip, regon, forma_prawna, miejscowosc, status, sad_rejestrowy, dataOstatniegoWpisu}'. Include which fields are always present vs optional.
• Add JSON Schema constraints to 'krs' parameter: pattern: '^\d{1,10}$' (or with hyphens), description: 'KRS number (1-10 digits, leading zeros added; hyphens stripped). Example: 0000123456 or 000-012-34-56'.
• Add error handling guidance to tool descriptions: 'Returns null if KRS not found in registry. If you have only a company name, use a separate search tool (not yet available in this server).'
• Clarify tool selection in descriptions. Rename or add context: get_entity → 'Get current KRS snapshot (latest status, address, identifiers)'; get_entity_full → 'Get full KRS history (all amendments and status changes)'; get_board → 'Get board/management summary (names, roles, representation method)'.