Loading ToolBench
MCP server providing access to Poland's largest business registry database - rejestr.io
Server has 6 tools with clear names following verb_noun convention and comprehensive descriptions. However, multiple critical gaps reduce overall quality: (1) Input schemas are present but lack explicit type validation and constraints for parameters; (2) Output schemas are completely undocumented, users cannot infer what fields to expect from tool responses; (3) Error handling is generic ('An error occurred') with no recovery guidance; (4) No pagination support for search results despite documentation mentioning paginated data; (5) Tool descriptions are verbose (often >200 chars) but lack actionable constraints and format requirements. Per-tool scores range from 55 to 75, averaging 68.
Retrieve comprehensive company information using KRS (National Court Register) number. KRS (Krajowy Rejestr Sądowy) is the Polish National Court Register number. This is the primary identifier for companies registered in Poland. Args: krs: KRS number in format "0000012345" (10 digits with leading zeros) or "12345" (without leading zeros). Both formats are accepted. Example: "0000012345" or "12345" Returns: Dictionary containing comprehensive company data including: - Basic information (name, legal form, status) - Registration numbers (KRS, REGON, NIP) - Addresses (headquarters, correspondence) - Share capital information - Management and representative data - Registration and modification dates Returns dict with "error" key if request fails
Search for companies by name in the rejestr.io database. This tool performs a search query using company name as the search term. The search supports partial matches and returns paginated results with companies matching the provided name pattern, sorted by relevance and capital. Args: name: Company name or partial name to search for (e.g., "Microsoft") Search is case-insensitive and supports partial matching Returns: Dictionary containing search results with the following structure: - liczba_wszystkich_wynikow (int): Total number of matching organizations - wyniki (list): List of organizations for current page, each including: * id (int): Organization ID (KRS number without leading zeros) * nazwy: Various name variants of the organization * numery: Registration numbers (KRS, NIP, REGON) * stan: Key data about organization status (active, liquidation, etc.) * adres: Main organization address from KRS * krs_wpisy: Information about key KRS entries * krs_powiazania_liczby: Number of connections with other entities Returns dict with "error" key if request fails Note: - This is a search endpoint returning paginated results (default 10 per page) - Results are sorted by text match relevance, modified by share capital - Additional search parameters (NIP, REGON, legal form, PKD codes, status flags, capital, size, location) are available in the API but not exposed in this tool - For exact company data after finding it, use get_company_info_using_krs or get_company_info_using_nip with the KRS/NIP from search results
No output schema documentation for any tool. Users/agents cannot infer return structure, field names, or types. Responses are opaque dicts with no guidance on what to extract.
Input parameter 'nip' in get_company_info_using_nip lacks format constraint validation. Description says '10-digit' and 'without special characters' but there is no enum, regex pattern, or minLength/maxLength in schema. LLM may pass invalid formats.
Input parameter 'chapter' in get_company_krs_documentation should be an enum with exactly [ogolny, oddzialy, akcje, wzmianki, zobowiazania, przeksztalcenia]. Currently defined as free-form string. This invites invalid values and LLM hallucination.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Retrieve comprehensive company information using NIP (Tax Identification Number). NIP (Numer Identyfikacji Podatkowej) is a Polish tax identification number. This tool searches the rejestr.io database and returns detailed company data including KRS number, REGON, addresses, legal form, and other registry information. Args: nip: 10-digit tax identification number without any special characters (e.g., "1234567890", not "123-456-78-90") Must be a valid, properly formatted NIP number Returns: Dictionary containing company data including: - Basic information (name, legal form, status) - Registration numbers (KRS, REGON, NIP) - Addresses (headquarters, correspondence) - Capital information - Registration dates Returns dict with "error" key if request fails
Retrieve specific chapter of KRS (National Court Register) documentation for a company. The KRS register is organized into chapters (divisions), each containing specific types of information about the company. This tool retrieves data from a selected chapter. Args: krs: KRS number in format "0000012345" or "12345" chapter: One of the following valid chapter names: - "ogolny" - General information (basic company data, purpose, representatives) - "oddzialy" - Branches and organizational units - "akcje" - Shares and shareholders information - "wzmianki" - Mentions and annotations (bankruptcy, liquidation, etc.) - "zobowiazania" - Liabilities and encumbrances - "przeksztalcenia" - Transformations and organizational changes Returns: Dictionary containing the requested chapter data with detailed structured information specific to that chapter. Returns dict with "error" key if request fails or if invalid chapter name is provided. Important: Before calling this tool, verify that the user has selected a valid chapter name from the list above. Invalid chapter names will result in API errors.
Retrieve detailed information about a person (individual) from the rejestr.io database. This tool fetches data about individuals registered in the business registry, typically company officers, board members, shareholders, or beneficiaries. The person ID must be obtained from other tools first. Args: id: Unique person identifier in the rejestr.io database This ID can be obtained from: - get_company_info_using_name() - from company structure data - get_company_info_using_nip() - from company structure data - get_company_info_using_krs() - from company structure data - get_beneficiary() - from beneficiary list Returns: Dictionary containing person data including: - Full name and personal details - PESEL (if available and public) - Addresses - Roles in companies - Related company connections Returns dict with "error" key if request fails Workflow: 1. First, use company search tools to find the company 2. Extract person IDs from the company data or beneficiary list 3. Then use this tool with the extracted ID to get detailed person information
Retrieve current API token balance from rejestr.io account. This tool checks the account balance (in PLN) for the rejestr.io API. Some operations like retrieving financial statements in JSON format cost tokens, so this tool helps monitor available credits before making expensive requests. Returns: String containing the current token balance in PLN format (e.g., "100.50 PLN") or error message if the request fails Example usage: Before downloading financial statements, check if there are sufficient tokens
Error handling is uniformly generic ('An error occurred: {e}'). No guidance on recovery, retry eligibility, or next steps for agent. Per pattern:recovery-guide, errors should indicate: Is this retryable? Is it a user input error? Can the agent ask the user for clarification?
get_company_info_using_name documents paginated results but tool does not expose pagination parameters (page, limit, offset). Agent cannot iterate through large result sets. Per pattern:paginated-result, search tools must include page/offset + limit params.
No idempotency declaration. If an agent retries get_company_info_using_nip after a transient network error, is it safe to call again? Docs are silent. Per pattern:idempotent-operation, read tools should declare idempotency.
Tool descriptions are verbose (150 - 250 chars) and include example values ('e.g., 1234567890', 'Microsoft'). Per pattern:tool-description, examples in descriptions are anti-pattern, LLMs reuse them literally rather than adapting to context. Use constraints (enum, pattern) instead.
API key is loaded from environment variable but never documented in the server or tool descriptions. Users won't know how to configure REJESTR_IO_API_KEY. While secret injection is correct, add setup documentation.