The KRS Poland MCP server exposes 2 READ_ONLY tools with well-formed JSON Schema validation patterns and regex constraints. However, it exhibits critical definition quality gaps: (1) tool descriptions are functionally identical and generic ('Get current/full status of the entity in KRS'), failing to distinguish when each tool should be used; (2) descriptions are 48 characters, at the lower end of the baseline range (p10=34, p90=392) and lack context on prerequisites, return content structure, or downstream chain opportunities; (3) output schemas are completely undocumented, handlers return structured text/JSON but no schema is declared for the response, making it impossible for LLMs to plan subsequent calls; (4) parameter descriptions exist but are terse Polish-language technical specs that lack actionable context for LLM reasoning ('Numer KRS (10 cyfr)' does not explain what KRS is, why it matters, or when to call this tool). The schema validation is strong (regex patterns ^[0]\d{9}$ and ^[pPsS]$ are correctly registered), but absence of documented output shape and vague parameter descriptions significantly hamper agent utility.
Identical descriptions for two semantically different tools. Both tools claim 'Get [current/full] status of the entity in KRS' but lack explanation of the difference, when to use each, or what distinguishes 'current' vs 'full' extract. This forces LLMs to guess or try both, wasting context.
No output schema documented. Handler returns JSON-stringified KRS extract wrapped in content[].text, but no schema defines the shape (fields, types, required keys) of the returned extract object. LLMs cannot plan downstream calls or validate result structure.
Parameter descriptions are terse, Polish-language technical abbreviations lacking context. 'Numer KRS (10 cyfr)' and 'Rejestr: P - przedsiębiorców, S - stowarzyszeń' do not explain what KRS is, why it's needed, or how to obtain a KRS number. LLMs cannot reason about these parameters without domain knowledge injection.
Get_Current_KRS_Record
Recommendations
Expand tool descriptions to 100 - 150 characters each. For Get_Current_KRS_Record: 'Retrieve the current, live status of a Polish business or association (entity) registered in the KRS system. Use this when you need real-time information. Requires a valid 10-digit KRS number and registry type (P=business, S=association). Returns JSON extract with entity name, address, and current status.' For Get_Full_KRS_Record: 'Retrieve the complete historical record of a Polish entity including all amendments, status changes, and full legal details. Use this for legal due diligence, comprehensive audits, or historical tracking. Requires KRS number and registry type. Returns detailed JSON with complete audit trail.'
Document the output schema for both tools. Add a 'returns' or 'outputSchema' field showing the shape of KrsExtract (e.g., { "properties": { "entity": { "type": "object", "properties": { "name": { "type": "string" }, "address": { "type": "string" }, ... } }, ... } }).
Enhance parameter descriptions with context. Rewrite 'krs' description: 'The 10-digit KRS number identifying the entity in the Polish Business Registry or Association Registry. Format: 0XXXXXXXXX (leading zero + 9 digits). Example: 0000123456. Obtain from official KRS search at https://ems.ms.gov.pl/ or from your business documentation.' Rewrite 'rejestr' description: 'Registry type. P = Krajowy Rejestr Sądowy (business registry), S = Stowarzyszeń (association registry). Case-insensitive.'
Add error categorization to handlers. When makeKRSRequest fails, return: { "content": [ { "type": "text", "text": "Failed to retrieve KRS record: <reason>. Retryable if network timeout. User-fixable if KRS number invalid or entity not found.", "_meta": {} } ] }.
Descriptions are 48 characters, well below baseline p50 (194 chars). Too brief to guide tool selection. Baseline best practice: 50 - 200 characters that answer WHAT, WHEN, and WHAT_RETURNS.
No error handling guidance. When makeKRSRequest fails or returns null, handler returns a plain text error message ('Nie udało się pobrać odpisu...'), but does not categorize the error as retryable, user-fixable, or fatal. No recovery steps are provided.
Get_Current_KRS_RecordGet_Full_KRS_Record
Consider splitting tools by use case clarity: Get_KRS_Current_Extract (for business register queries) and Get_KRS_Association_Extract (if association handling differs significantly), or keep both and clarify in descriptions when each is appropriate.
Add natural-language identifiers. Allow 'krs' parameter to accept both 10-digit KRS number AND entity name with resolution inside the tool via a separate name-to-KRS lookup endpoint (if available), improving usability.
Document limits. If the KRS extract response can be very large, state in the description: 'Returns up to 5,000 characters of JSON. For extremely complex entities, consider requesting only the current extract.'
Localize descriptions. While Polish technical terms are necessary, provide English translation in parentheses for international LLM audiences: 'Rejestr: P (Business Registry) or S (Association Registry).'