Find all companies registered at a given Czech address. Useful for due diligence (virtual offices, shell companies), real estate research, or competitor mapping in a building.
| Name | Required | Description | Default |
|---|---|---|---|
| psc | No | Postal code (PSČ), optional. | |
| city | Yes | City name, e.g. "Praha". | |
| pocet | No | Max results (default 20). | |
| street | Yes | Street name (nazev ulice), e.g. "Radlická". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the Czech address scope and the fact that it returns registered companies. However, it does not disclose that results are limited by the 'pocet' parameter (default 20 despite saying 'all'), nor pagination behavior. Since annotations lower the bar, this is a solid 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and scoped to Czech addresses, followed by relevant use cases. Every sentence earns its place with no redundant information. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and usage context, which is good given moderate complexity (4 params, no output schema). It does not describe the return structure, which could be helpful but is not essential given the tool name and description make the output obvious. The absence of output schema means the description carries some burden, but the description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning about parameters beyond what the schema already provides. It mentions 'Czech address' generically, but street, city, and psc are all well-documented in the schema. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find all companies registered at a given Czech address.' This uses a specific verb (find) and resource (companies by address), and the use cases (due diligence, real estate research) make the purpose unambiguous. It distinguishes itself from sibling tools like search_by_nace or search_companies by focusing on address-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Useful for due diligence, virtual offices, shell companies, real estate research, or competitor mapping in a building'). It does not explicitly name alternatives or exclusions, but the use cases strongly imply address-based queries. It lacks an explicit 'use search_companies for name-based queries', so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of Czech company data: VAT status, bank accounts, historical changes, statutory bodies, basic lookup by IČO, address search, NACE search, combined search, DIČ validation, and monitoring. No significant overlap.
All tools use consistent snake_case and follow a verb_noun pattern (e.g., check_vat_payer, get_statutaries, search_companies). No mixing of conventions.
10 tools is appropriate for the domain of Czech company information, covering lookups, searches, VAT checks, history, and monitoring. Not excessive nor insufficient.
Core operations for the ARES domain are covered: lookup, search, VAT and DIČ checks, history, and statutory data. The watch_entity tool is a stub, and there might be missing advanced queries, but the set is largely complete for intended use.