Loading ToolBench
Model Context Protocol server for the Polish GUS REGON business register (BIR1 API).
Six tools with clear verb-noun naming (search_*, get_*, list_) and comprehensive descriptions (100-250 chars each). All tools have input schemas with type definitions and parameter descriptions. Output structure documented via _envelope pattern. However, no explicit output schema documentation in docstrings, no error handling guidance, no parameter constraints (enums), and no tool annotations (readOnlyHint). Descriptions are good but could be more LLM-optimized with explicit 'when to use' and 'what it returns' sections.
Fetch a detailed REGON report for one entity by REGON. Choose report_type from list_report_types(), based on the entity's `type` and `silo_id` returned by a search.
List valid report_type values for get_full_report(), with guidance. These are the BIR1.1 report names. Picking the right report: - type "P" (legal person) -> BIR11OsPrawna - type "F" (natural person) -> by silo_id: 1 -> BIR11OsFizycznaDzialalnoscCeidg 2 -> BIR11OsFizycznaDzialalnoscRolnicza 3 -> BIR11OsFizycznaDzialalnoscPozostala 4 -> BIR11OsFizycznaDzialalnoscSkreslonaDo20141108 - local units (LP / LF) -> BIR11JednLokalnaOsPrawnej / ...OsFizycznej
Look up up to 20 entities of the same identifier type in one call. id_type must be one of: "nip", "krs", "regon9", "regon14". The response adds `requested` (normalized inputs) and `unmatched` (requested ids with no returned row) so partial results are explicit. For KRS the service does not echo the KRS in search rows, so `unmatched` is null there.
Look up a Polish business entity by KRS (10-digit court-register number).
Look up a Polish business entity by NIP (10-digit tax id). Returns basic registry data (name, REGON, address, entity type). Use the returned REGON with get_full_report() for the detailed record.
No output schema documentation in tool docstrings. LLMs cannot plan downstream calls without knowing response structure (count, results, source fields).
No enum constraints on id_type parameter in search_bulk. Accepts free-form strings ('nip', 'krs', 'regon9', 'regon14'), LLMs may hallucinate invalid values like 'nip_number' or 'regon_id'.
No error handling guidance in descriptions. Tools validate inputs (normalize_nip, normalize_regon, normalize_krs) but docstrings do not explain what happens on invalid input or how to recover.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Look up a Polish business entity by REGON (9- or 14-digit statistical id).
search_by_regon and search_by_krs descriptions are minimal (60 chars). Missing context on when to use each vs search_by_nip, and what data is returned.
No tool annotations (readOnlyHint). All six tools are read-only but this is not declared in the tool definition, forcing LLMs to infer safety from descriptions.