Czech & Slovak business registry — company lookup by IČO, name, legal form, VAT. Official ARES.
Scored across 10 tools
Most tools have clearly distinct purposes, but search_companies and search_by_address/search_by_nace overlap significantly, as search_companies explicitly covers address and NACE searches as well. Descriptions acknowledge this overlap, but an agent might still be unsure which to pick for a combined search.
The set is mostly consistent with verb_noun patterns, but there are deviations like lookup_by_ico and get_history (get_ vs. lookup_ vs. check_ vs. validate_). It remains readable and predictable enough.
10 tools is well-scoped for a Czech business registry server, covering lookup, search, validation, and due diligence functions without excess.
The surface covers core CRUD-like lookups and validation well, including VAT, bank accounts, statutaries, and searches. However, watch_entity is a stub that persists nothing, and there is no tool to fetch a full company record by other identifiers beyond IČO, and no update/create operations (appropriate for a read-only registry).
Check whether a Czech company is a registered VAT payer (plátce DPH). If yes, returns DIČ, financial office, and any transparent bank accounts (payment details).
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO (7-8 digits). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and open-world, so the safety profile is covered. The description adds conditional behavior ('If yes') and specifies the returned fields (DIČ, financial office, transparent bank accounts), which is valuable beyond annotations. No contradiction.
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 a single, focused sentence that immediately states the action and output. It is concise and well-structured, with no wasted words.
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?
For a low-complexity tool with one parameter, the description covers the core behavior and outputs, complemented by schema and annotations. It is complete enough for an agent to understand the tool's purpose and expected results, though it does not explicitly state what happens when the company is not a VAT payer (e.g., return type), which would make it fully complete.
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?
The sole parameter 'ico' is fully documented in the schema with its description 'Czech IČO (7-8 digits)' (100% coverage). The tool description does not add further parameter details, so it relies on the schema; baseline 3 is appropriate.
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 specifies the exact purpose: checking VAT payer status for a Czech company, with a specific verb ('Check') and resource ('Czech company'). It distinguishes itself from siblings like validate_dic (which validates DIČ format) and lookup_by_ico (general lookup) by focusing on VAT payer status and the specific output fields (DIČ, financial office, bank accounts).
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 clearly implies when to use it: when you need to determine VAT payer registration and associated details. However, it does not explicitly mention alternatives or exclusion scenarios, such as when to prefer validate_dic for DIČ validation, which is a minor gap. The context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transparent bank accounts published for this company (only available for VAT-registered subjects). Useful to verify payment details on an invoice match the company.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO (7-8 digits). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds an important non-obvious constraint: availability is limited to VAT-registered subjects, and data is 'published' transparent accounts. This goes beyond the annotations without contradicting them.
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?
Two short sentences, no unnecessary words. The core action is front-loaded, and the use case is stated efficiently.
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?
For a single-parameter, read-only tool with no output schema, the description fully covers purpose, usage context, and a key eligibility constraint. It does not describe the return format, but the tool is simple enough that this is not a major gap.
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?
The only parameter 'ico' is fully described in the schema (100% coverage), specifying Czech IČO with 7-8 digits. The description does not add further parameter details, but the schema already carries the semantic weight, so baseline 3 applies.
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 uses a specific verb 'Get' and clearly identifies the resource 'transparent bank accounts' scoped to 'this company'. It is clearly distinct from sibling tools like check_vat_payer or get_statutaries, which focus on other data.
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?
Provides a concrete use case ('verify payment details on an invoice match the company') and a key prerequisite ('only available for VAT-registered subjects'). It does not explicitly name alternatives, but the sibling tools address different resources, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical record of a company (previous names, registered address changes, trade license history). Useful for due diligence.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO (7-8 digits). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context by specifying what kind of historical data is returned (names, address changes, license history), giving the agent a clearer expectation of the tool's output. This goes beyond the annotations, though it doesn't cover edge cases like empty results or data completeness.
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 long and front-loaded with the core purpose. The second sentence about due diligence adds relevant context without fluff. Every word earns its place, making it highly concise and well-structured.
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?
Given the tool's simplicity (one param, no output schema) and existing annotations, the description covers the essential use case and data scope. However, it could mention potential caveats like incomplete history or the completeness of the data, especially since openWorldHint is true. Minor gap in full completeness.
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?
The schema already fully documents the 'ico' parameter with its format ('Czech IČO (7-8 digits)'). The description does not add additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
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 uses a specific verb 'Get' with a clear resource 'historical record of a company' and enumerates specific data types (previous names, registered address changes, trade license history). This distinguishes it from sibling tools like lookup_by_ico or get_statutaries, making its purpose unambiguous.
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 phrase 'Useful for due diligence' provides a use case but does not explicitly compare this tool to alternatives or state when not to use it. It implies usage context without giving clear directives, such as 'use lookup_by_ico for current data'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current statutory body (jednatelé, představenstvo, etc.) of a Czech company — who can legally act on its behalf. Returns active members only (with valid zápis, not yet removed). Essential for due diligence and compliance checks.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO (7-8 digits). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already declaring the safe read nature, the description adds that it 'Returns active members only (with valid zápis, not yet removed),' which is a key behavioral detail about filtering and data freshness. This goes beyond the annotations without contradiction.
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: the first states purpose and meaning, the second adds behavioral detail and use case. No wasted words, and key information is front-loaded.
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 tool is simple (one parameter, no output schema), and the description covers what it returns (active members), the legal context, and the use case. This provides enough information 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?
The single parameter ico is fully described in the schema as 'Czech IČO (7-8 digits).' The description reinforces that the tool targets Czech companies but adds no new parameter semantics beyond the schema, so a baseline score is appropriate.
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 uses a specific verb 'Get' and identifies the resource: statutory body of a Czech company, with clarifying examples (jednatelé, představenstvo) and explanation of legal significance. This clearly distinguishes it from sibling tools like get_bank_accounts or search_companies.
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?
It explicitly states 'Essential for due diligence and compliance checks,' providing a clear use case. It does not mention alternatives or exclusions, but the context is sufficient for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Czech company record by its IČO (8-digit Business ID). Returns official name, registered address, legal form, VAT ID (DIČ), founding date, and trade license activities. Returns null if IČO is not found in ARES.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. Examples: "11122234", "87654326". Auto-validated with MOD11 checksum. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, but the description adds meaningful behavioral context: returns null when IČO is not found, returns specific fields, and sources from ARES. This goes beyond the annotation and is valuable for the agent.
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?
Two tight sentences: the first states the action and input, the second lists return fields and null behavior. No wasted words, information is front-loaded.
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?
For a simple single-parameter read-only lookup with no output schema, the description covers the purpose, input, return contents, and edge case (not found). This is sufficient for an agent to invoke it 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 coverage is 100% and the schema already provides detailed parameter semantics (7/8 digits, examples, MOD11 validation). The description adds no extra parameter meaning and even says '8-digit' while the schema permits 7 or 8 digits, though the schema clarifies this.
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 a specific action ('Get a single Czech company record by its IČO') and resource, and lists the exact returned fields. It distinguishes itself from sibling search/list tools by emphasizing 'single' record 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 context is clear: use when you have an IČO and need a single company record. It does not explicitly name alternatives or exclusion criteria, but the 'single' vs. sibling search tools is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Find Czech companies by CZ-NACE activity code (economic sector classification). Example: "62" = IT, "47" = retail, "86" = healthcare. Optional city filter. Useful for market research.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city filter. | |
| nace | Yes | CZ-NACE code, 2-6 digits (e.g., "62" for IT, "62010" for programming services). | |
| pocet | No | Max results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the NACE code examples and optional city filter, but does not disclose return format, pagination, or any edge-case behavior. This is acceptable but minimal beyond annotations.
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?
Three sentences, front-loaded with the core purpose, followed by useful examples and a use-case line. No wasted words; each sentence earns its place.
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?
For a simple read-only search tool with full schema coverage and annotations, the description is adequate. It explains the key search dimension (NACE) and optional filter, and the title/annotations confirm read-only and open-world behavior. It doesn't specify return fields, but the lack of an output schema makes this a minor gap.
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 a few extra NACE examples and mentions the optional city filter, but these largely duplicate schema info. It doesn't fundamentally extend parameter understanding.
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 uses a specific verb ('Find') with a clear resource ('Czech companies') and a precise scope ('by CZ-NACE activity code'). It distinguishes from sibling tools like search_by_address and lookup_by_ico by focusing on the NACE classification, and the examples ('62'=IT, '47'=retail) reinforce the purpose.
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?
It explicitly states a use case ('Useful for market research') and implies the tool should be used when filtering by economic sector. It doesn't mention alternatives or exclusions, but the context is clear enough for an agent to choose this over a generic company search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ARES by company name, city, street, PSČ, or NACE code. Combines all filters with AND. Useful when user knows name but not IČO, looking for companies in a building, or all businesses in a sector.
| Name | Required | Description | Default |
|---|---|---|---|
| psc | No | Filter by postal code (PSČ), 5-digit number. | |
| city | No | Filter by city (nazev obce), e.g. "Praha". | |
| nace | No | Filter by CZ-NACE activity codes, 2-6 digits. E.g., ["62"] for IT. | |
| pocet | No | Max results (1-100, default 10). | |
| query | No | Partial or full company name (obchodní jméno). | |
| start | No | Pagination offset (default 0). | |
| street | No | Filter by 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. The description adds the non-obvious behavioral detail that 'Combines all filters with AND', which materially affects query construction and result interpretation. It does not disclose return format or pagination trends, but those are partially described in the schema.
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?
Two sentences, both dense with meaning: the first defines the search scope, the second explains filter combination and typical use cases. No redundancy or filler.
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?
For a read-only search tool with 7 optional parameters and no output schema, the description provides purpose, usage scenarios, and filter logic. It could mention pagination (start, pocet) or result limits, but those are already in the schema. 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 coverage is 100%, so parameters are individually documented. The description adds semantic value by clarifying that all filters are combined with AND, which is a cross-parameter behavior not obvious from individual descriptions. It also maps the free-text query and structured filters to real-world search intentions.
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 'Search ARES by company name, city, street, PSČ, or NACE code' — a specific verb, resource, and supported filters. It distinguishes from siblings like lookup_by_ico (by IČO), search_by_address, and search_by_nace by covering a multi-filter search scenario.
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 concrete use cases: 'when user knows name but not IČO, looking for companies in a building, or all businesses in a sector.' It implies alternatives (e.g., lookup_by_ico for IČO) without naming them explicitly, but the context is clear enough for an agent to make a good choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a Czech DIČ (VAT ID). Format check: "CZ" + 8-10 digits. For 8-digit tail (legal entities) also runs MOD11 checksum against the embedded IČO.
| Name | Required | Description | Default |
|---|---|---|---|
| dic | Yes | Czech DIČ — e.g., "CZ26168685". Whitespace and case tolerated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, and the description adds valuable behavioral details beyond that: the format check for 'CZ'+8-10 digits and MOD11 checksum for 8-digit tails. This gives the agent a clear picture of what happens during validation with no contradiction to annotations.
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 primary purpose, and includes only relevant technical details. No filler or redundancy.
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?
Given the simple input schema and annotations, the description covers the core behavior well. However, since there is no output schema, the description does not mention what the tool returns (e.g., boolean, validation errors), which is a gap in completeness for an agent.
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?
The schema fully describes the parameter 'dic' with an example and format tolerances, so schema coverage is 100%. The description reinforces the format but does not add new parameter-level meaning beyond what the schema already provides, earning a baseline 3.
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 validates a Czech DIČ (VAT ID) with a verb+resource structure and gives specific details about format and checksum. It is immediately understandable, though it does not explicitly differentiate from the sibling tool check_vat_payer, which also relates to VAT validation.
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?
No guidance is provided on when to use this tool versus alternatives. The description implies usage (validate a DIČ) but does not mention check_vat_payer or any exclusion criteria, leaving the agent to infer which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start onboarding for free monitoring of one Czech company by IČO. Stub only — persists nothing yet. Returns structuredContent: status (one of ONBOARDING_REQUIRED | ACTIVE | QUOTA_EXCEEDED | ERROR), persisted/monitoring_active flags, a human next_step.url for onboarding (the user completes onboarding + GDPR consent themselves — do not open the link or submit data on their behalf), and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO (7-8 digits). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the stub nature ('persists nothing yet'), the exact return structure (status enum, flags, next_step.url, pricing), and a critical safety note about not opening the onboarding link or submitting data on the user's behalf. This is rich behavioral context that annotations alone do not provide.
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 concise and front-loaded: the core purpose is stated in the first sentence, followed by essential caveats and return details. All sentences add value, with no filler or redundancy.
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?
Given the tool has only one parameter, no output schema, and moderate complexity, the description fully compensates by enumerating the return fields, statuses, flags, next_step.url, pricing, and user responsibility. It is coherent and leaves no major gaps for an agent to infer.
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?
The schema already describes the only parameter 'ico' (Czech IČO, 7-8 digits) with 100% coverage. The description merely reiterates 'by IČO' without adding new details, so it provides no additional meaning beyond what the schema documents.
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 starts onboarding for free monitoring of one Czech company by IČO. This specific verb ('start onboarding') and resource ('monitoring of one Czech company') distinguishes it from sibling lookup/search tools, which are about querying data rather than ongoing monitoring.
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 gives clear context: use this tool to initiate monitoring of a company via IČO, as opposed to one-time lookups from sibling tools. It does not explicitly name alternatives or exclusions, but the purpose is self-evident enough for an agent to infer when to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
watch_entity1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": false,
- "properties": {
- "agent_guidance": {
- "type": "string"
- },
- "delivery_channel": {
- "type": "null"
- },
- "free_quota": {
- "additionalProperties": false,
- "properties": {
- "limit": {
- "type": "number"
- },
- "used": {
- "type": "number"
- }
- },
- "required": [
- "limit",
- "used"
- ],
- "type": "object"
- },
- "ico": {
- "type": "string"
- },
- "locale": {
- "const": "cs",
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "monitoring_active": {
- "type": "boolean"
- },
- "next_step": {
- "additionalProperties": false,
- "properties": {
- "action": {
- "const": "complete_onboarding",
- "type": "string"
- },
- "actor": {
- "const": "human",
- "type": "string"
- },
- "requires": {
- "items": {
- "enum": [
- "notification_channel",
- "gdpr_consent"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "actor",
- "action",
- "url",
- "requires"
- ],
- "type": "object"
- },
- "persisted": {
- "type": "boolean"
- },
- "pricing": {
- "additionalProperties": false,
- "properties": {
- "solo": {
- "type": "string"
- },
- "team": {
- "type": "string"
- }
- },
- "required": [
- "solo",
- "team"
- ],
- "type": "object"
- },
- "schema_version": {
- "const": 1,
- "type": "number"
- },
- "status": {
- "enum": [
- "ONBOARDING_REQUIRED",
- "ACTIVE",
- "QUOTA_EXCEEDED",
- "ERROR"
- ],
- "type": "string"
- },
- "tier": {
- "const": "free",
- "type": "string"
- }
- },
- "required": [
- "schema_version",
- "status",
- "persisted",
- "monitoring_active",
- "ico",
- "tier",
- "free_quota",
- "delivery_channel",
- "next_step",
- "agent_guidance",
- "pricing",
- "message",
- "locale"
- ],
- "type": "object"
-}New value: +nullwatch_entity1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "agent_guidance": {
+ "type": "string"
+ },
+ "delivery_channel": {
+ "type": "null"
+ },
+ "free_quota": {
+ "additionalProperties": false,
+ "properties": {
+ "limit": {
+ "type": "number"
+ },
+ "used": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "limit",
+ "used"
+ ],
+ "type": "object"
+ },
+ "ico": {
+ "type": "string"
+ },
+ "locale": {
+ "const": "cs",
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "monitoring_active": {
+ "type": "boolean"
+ },
+ "next_step": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "const": "complete_onboarding",
+ "type": "string"
+ },
+ "actor": {
+ "const": "human",
+ "type": "string"
+ },
+ "requires": {
+ "items": {
+ "enum": [
+ "notification_channel",
+ "gdpr_consent"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "actor",
+ "action",
+ "url",
+ "requires"
+ ],
+ "type": "object"
+ },
+ "persisted": {
+ "type": "boolean"
+ },
+ "pricing": {
+ "additionalProperties": false,
+ "properties": {
+ "solo": {
+ "type": "string"
+ },
+ "team": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "solo",
+ "team"
+ ],
+ "type": "object"
+ },
+ "schema_version": {
+ "const": 1,
+ "type": "number"
+ },
+ "status": {
+ "enum": [
+ "ONBOARDING_REQUIRED",
+ "ACTIVE",
+ "QUOTA_EXCEEDED",
+ "ERROR"
+ ],
+ "type": "string"
+ },
+ "tier": {
+ "const": "free",
+ "type": "string"
+ }
+ },
+ "required": [
+ "schema_version",
+ "status",
+ "persisted",
+ "monitoring_active",
+ "ico",
+ "tier",
+ "free_quota",
+ "delivery_channel",
+ "next_step",
+ "agent_guidance",
+ "pricing",
+ "message",
+ "locale"
+ ],
+ "type": "object"
+}lookup_by_ico1 field changedInput schema / properties / ico / descriptionPrevious value: -"Czech IČO — 7 or 8 digits. Examples: \"27074358\", \"61388581\". Auto-validated with MOD11 checksum."New value: +"Czech IČO — 7 or 8 digits. Examples: \"11122234\", \"87654326\". Auto-validated with MOD11 checksum."watch_entitycheck_bulk_dph_payercheck_dph_payercheck_vat_payerget_bank_accountsget_historyget_statutarieslist_unreliable_payerslookup_by_icosearch_by_addresssearch_by_nacesearch_companiesvalidate_diccheck_bulk_dph_payercheck_dph_payercheck_vat_payerget_bank_accountsget_historyget_statutarieslist_unreliable_payerslookup_by_icosearch_by_addresssearch_by_nacesearch_companiesvalidate_diccheck_ico_insolvencycheck_vat_payerget_bank_accountsget_historyget_statutarieslookup_by_icopoll_isir_eventssearch_by_addresssearch_by_nacesearch_companiessearch_person_insolvencyvalidate_diccheck_ico_insolvencycheck_vat_payerget_bank_accountsget_historyget_statutarieslookup_by_icopoll_isir_eventssearch_by_addresssearch_by_nacesearch_companiessearch_person_insolvencyvalidate_diccheck_ico_insolvencycheck_vat_payerget_bank_accountsget_historyget_statutarieslookup_by_icopoll_isir_eventssearch_by_addresssearch_by_nacesearch_companiessearch_person_insolvencyvalidate_diccheck_ico_insolvencycheck_vat_payerget_bank_accountsget_historyget_statutarieslookup_by_icopoll_isir_eventssearch_by_addresssearch_by_nacesearch_companiessearch_person_insolvencyvalidate_dicsearch_by_addresssearch_by_nacesearch_companies5 fields changedInput schema / properties / city / descriptionPrevious value: -"Filter by city (nazev obce)."New value: +"Filter by city (nazev obce), e.g. \"Praha\"."Input schema / properties / naceAdded value: +{
+ "description": "Filter by CZ-NACE activity codes, 2-6 digits. E.g., [\"62\"] for IT.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / pocet / descriptionPrevious value: -"Max results to return (1-100, default 10)."New value: +"Max results (1-100, default 10)."Input schema / properties / psc / descriptionPrevious value: -"Filter by postal code (PSČ)."New value: +"Filter by postal code (PSČ), 5-digit number."Input schema / properties / streetAdded value: +{
+ "description": "Filter by street name (nazev ulice), e.g. \"Radlická\".",
+ "type": "string"
+}check_vat_payerget_bank_accountsget_historyget_statutarieslookup_by_icosearch_companiesvalidate_dicCzech ARES company registry: VAT, insolvency, RÚIAN addresses, IČO/DIČ checks. All free, no auth.
Czech business register (ARES) — look up any Czech company or sole trader by IČO or by name, from…
Slovak and Czech company registers: lookup, VAT payers, e-invoicing readiness, company history.
Vyhledávání a detail českých firem, finanční výkazy a ukazatele z veřejných rejstříků.
Add one secure layer between your agents and this server.
