Estonian companies, EMTAK, grants and tenders from public registers.
Scored across 10 tools
Each tool targets a clearly distinct task: single-company risk checks, multi-company comparison, filtered discovery, name search, full profile retrieval, funding calls, procurement notices, regional stats, risk scans, and sector stats. Cross-references in descriptions explicitly steer the agent to the right tool for overlapping concerns like tax debt or company lookup.
All names use lowercase snake_case, which is consistent and readable. However, the set mixes verb-led names like check_counterparty and find_companies with noun-led names like procurement_notices and sector_stats, so the verb_noun pattern is not universal.
Ten tools is well within the ideal range and each tool covers a distinct aspect of business-data lookup, comparison, risk assessment, and funding/procurement discovery. No tool feels redundant or like filler.
The server provides comprehensive read-only coverage for its domain: company identity, financials, risk signals, comparisons, sector and regional statistics, plus public funding and procurement opportunities. There are no obvious dead ends or critical missing operations for the stated purpose.
Status, tax debt, last filed report, overdue days, insolvency or liquidation notices, and distress for one registry code. Use this before invoicing. Use get_company for the wider financial card, and risk_signals to scan many companies for one signal.
| Name | Required | Description | Default |
|---|---|---|---|
| registry_code | Yes | 8-digit commercial register code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, establishing that this is a safe read operation. The description adds useful scope detail ('for one registry code') and enumerates the returned information, but it does not disclose additional behavioral caveats such as data freshness, response format, or error conditions. This is adequate but not rich.
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 with no filler. The first sentence front-loads the tool's core output and scope, while the second provides usage guidance and sibling routes. Every phrase 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, single-parameter tool with full schema coverage and no output schema, the description provides all essential context: what data is returned, when to use it, and which alternatives exist. Nothing critical is missing for correct selection or invocation.
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 describes the only parameter, registry_code, as an '8-digit commercial register code' (100% coverage). The description's mention of 'one registry code' reinforces the cardinality but adds no new semantic details beyond the schema, so the baseline score of 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 enumerates the data fields returned (status, tax debt, last filed report, overdue days, insolvency/liquidation notices, distress) and explicitly names sibling tools, so an agent can tell it apart from get_company and risk_signals. However, it lacks an explicit operative verb like 'Returns' or 'Checks', making it slightly less crisp than a full verb+resource statement.
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 an explicit when-to-use directive ('Use this before invoicing') and names clear alternatives: 'Use get_company for the wider financial card, and risk_signals to scan many companies for one signal.' This is direct, actionable guidance that routes the agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare up to four companies for one year: accounts, tax debt, distress, and revenue percentile. Use find_companies to discover codes first, and sector_stats for the industry median rather than named peers.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Financial year. Defaults to the snapshot year. | |
| registry_codes | Yes | One to four 8-digit registry codes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, so the bar is lower. The description adds useful behavioral scope: it caps comparisons at four companies, restricts to one year, and enumerates the exact comparison dimensions, which tells the agent what kind of result content to expect.
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 tightly packed sentences with no filler. The core capability is front-loaded, and the routing guidance to find_companies and sector_stats appears immediately after.
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 tool with two well-documented parameters and no output schema, the description is complete: it states the input constraints, the data dimensions returned, and the related tools needed for correct invocation.
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 schema fully documents both parameters. The description mostly restates the same limits (up to four codes, one year) without adding deeper meaning about parameter formatting or behavior beyond what the schema already provides.
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 states a specific verb ('Compare') and resource ('companies') with concrete constraints: up to four companies, one year, and four data dimensions (accounts, tax debt, distress, revenue percentile). It also differentiates the tool from siblings by directing users to find_companies for code discovery and sector_stats for industry medians.
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 explicitly tells the agent to use find_companies first to discover registry codes and sector_stats when an industry median is needed instead of named-peer comparison. This gives clear when-to-use and alternative-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capped company list sorted by revenue descending, filtered by county, EMTAK, revenue, employees, or no current tax debt. County aliases accepted. No personal emails or phone numbers. Use search_companies for a name lookup, and get_company on a code from this list.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Financial year | |
| emtak | No | EMTAK code or prefix | |
| limit | No | At most 50 companies | |
| county | No | County name or alias. Valid: Ida-Viru maakond, Lääne-Viru maakond, Harju maakond, Hiiu maakond, Jõgeva maakond, Järva maakond, Lääne maakond, Põlva maakond, Pärnu maakond, Rapla maakond, Saare maakond, Tartu maakond, Valga maakond, Viljandi maakond, Võru maakond, Maakond puudu. | |
| max_revenue | No | Maximum annual revenue, EUR | |
| min_revenue | No | Minimum annual revenue, EUR | |
| no_tax_debt | No | Keep only companies with no current tax debt | |
| max_employees | No | Maximum average employees | |
| min_employees | No | Minimum average employees |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds valuable behavioral context: the list is capped, sorted by revenue descending, does not include personal emails or phone numbers, and accepts county aliases. These are meaningful details beyond the structured 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?
Two sentences pack a remarkable amount of information: cap, sort order, filter types, exclusions, alias acceptance, and usage guidance. Every word earns its place, and the core function 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 tool with 9 optional parameters and no output schema, the description covers the essential behavioral aspects: cap and sort, exclusions, alias handling, and routing to sibling tools. It even implies the return contains company codes ('get_company on a code from this list'), which is a helpful hint. No critical information is missing for correct invocation.
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 each parameter already has a clear description. The tool description mentions the filter categories (county, EMTAK, revenue, employees, no tax debt) but does not add new meaning beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter documentation.
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 returns a capped list of companies sorted by revenue descending, with multiple filter options. It distinguishes itself from search_companies by explicitly noting it is not for name lookup, making the 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 description explicitly directs users to 'Use search_companies for a name lookup, and get_company on a code from this list.' This tells the agent exactly when to use alternatives, eliminating ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Company profile, latest accounts (or all years via sections), last 8 EMTA quarters, tax debt, aid, licences, announcements, legal-entity owners, peer percentiles, and similar companies. Optional sections add permits, EMTAK activities, EU grants, history, and state contracts. Use check_counterparty when the question is only status, tax debt, a missing report, or insolvency. Use search_companies when you only have a name.
| Name | Required | Description | Default |
|---|---|---|---|
| sections | No | Optional extras: permits, activities, grants (EU projects), history (company events), state_contracts, financials (all years). Default omits these and returns latest financials only. | |
| registry_code | Yes | 8-digit commercial register code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds meaningful behavioral context by stating what data is included by default, what sections can extend the response, and how selecting sections changes from latest financials to all years. It does not describe output shape or error behavior, but those are less critical for a read-only profile tool.
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 information-dense without filler: the first sentence inventories the main payload, the second covers optional sections, and the final two sentences provide routing rules. Every sentence earns its place, and the structure front-loads the most important content.
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 that there is no output schema, the description carries the burden of explaining what the tool returns, and it does so thoroughly by listing the main data categories and optional sections. It also covers the key decision point of when to use lighter alternatives. Nothing essential for correctly selecting or invoking this tool is missing.
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 of 3 applies: both registry_code and sections already have clear descriptions in the schema. The description restates the optional sections and highlights the 'latest accounts vs. all years' behavior, which slightly reinforces the schema but does not add substantially new parameter-level meaning.
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 identifies the resource (a company profile) and enumerates the exact data categories returned, so an agent knows what to expect. It also names two sibling tools that cover different question types, which helps disambiguation. It falls just short of a 5 because it opens with a noun phrase ('Company profile') rather than an explicit action verb like 'returns' or 'fetches'.
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 explicit routing guidance: use check_counterparty when the question is only status, tax debt, missing reports, or insolvency, and use search_companies when only a name is available. This is direct, actionable guidance that prevents the agent from overusing get_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open funding calls from EIS, PRIA, and KIK. Use procurement_notices for public tenders. This tool does not draft an application.
| Name | Required | Description | Default |
|---|---|---|---|
| emtak | No | EMTAK code. Matched on the division when the call has rules. | |
| county | No | County name or alias. Valid: Ida-Viru maakond, Lääne-Viru maakond, Harju maakond, Hiiu maakond, Jõgeva maakond, Järva maakond, Lääne maakond, Põlva maakond, Pärnu maakond, Rapla maakond, Saare maakond, Tartu maakond, Valga maakond, Viljandi maakond, Võru maakond, Maakond puudu. | |
| provider | No | Funder, for example EIS | |
| deadline_within_days | No | Keep calls whose deadline is within this many days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the important behavioral note that it does not draft an application, which is beyond the annotations. It does not mention pagination or response format, but for a read-only list tool with these annotations, this is acceptable.
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 with zero waste. The purpose is front-loaded, the alternative is given, and the limitation is stated. Perfectly structured for quick agent scanning.
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 list tool with optional filters, the description covers the core purpose, the providers, and the key exclusion. It lacks a note on the response format or pagination, but given the low complexity and no output schema, this is a minor gap. The description is sufficient for an agent to decide when to call it.
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 each parameter already has a clear description (e.g., emtak 'Matched on the division when the call has rules', provider 'Funder, for example EIS'). The description does not add any additional parameter-level meaning beyond the schema, so the baseline 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 states a specific resource (funding calls) and the providers (EIS, PRIA, KIK), and explicitly differentiates from the sibling procurement_notices for public tenders. The verb 'Open' is slightly ambiguous but the intent is clear: return open calls. It fully distinguishes this tool from the sibling list.
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?
Explicitly states when not to use it ('Use procurement_notices for public tenders') and adds a limitation ('This tool does not draft an application'). This gives the agent clear routing logic and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public procurement notices with buyer, deadline, and CPV. Title/buyer text uses contains matching. Opaque cursor pagination. Companies and authorities only. Use open_calls for grants and funding calls, not tenders.
| Name | Required | Description | Default |
|---|---|---|---|
| cpv | No | CPV code prefix | |
| days | No | Published within this many days | |
| buyer | No | Buyer name | |
| limit | No | At most 25 notices | |
| query | No | Title or buyer text (contains match on folded title/authority) | |
| cursor | No | Opaque cursor from a previous next_cursor for the next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds useful behavioral details: mention of 'contains matching' for text searches and 'opaque cursor pagination,' which go beyond the schema. However, it does not disclose performance characteristics, rate limits, or what the response contains beyond the mention of fields like buyer, deadline, and CPV. Given annotations cover the core safety profile, a 3 is appropriate.
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 with zero fluff. It front-loads the purpose and key attributes, then adds the matching behavior and pagination note, and finally the routing to open_calls. Every sentence 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 moderate complexity (6 params, all documented in schema, no output schema), the description covers the essential behavioral aspects: matching semantics, pagination, and scope (companies/authorities). It also provides a clear alternative for non-tender opportunities. It does not explain how to use the cursor in practice (e.g., that next_cursor appears in the response), but that is implied and the schema covers the cursor parameter. Overall, it is complete enough for an agent to invoke 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 schema already documents all parameters thoroughly. The description adds value by specifying that title/buyer text uses contains matching and that cursor is opaque, which clarifies parameter semantics beyond the schema's simple field names. It also clarifies that the 'cpv' parameter is a CPV code prefix, which is not fully explicit in the schema's 'CPV code prefix' description. This goes beyond the baseline of 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 identifies the tool as fetching public procurement notices and lists key attributes (buyer, deadline, CPV). It clearly distinguishes it from the sibling open_calls by noting that open_calls is for grants and funding calls, not tenders. However, it does not fully describe the exact scope (e.g., country-specific public procurement), which is a minor gap.
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 explicitly directs users to use open_calls for grants and funding calls instead of tenders, which provides clear when-not-to-use guidance and differentiates from a key sibling. It also hints at the tool's scope by saying 'Companies and authorities only,' but does not explicitly say when to use this tool versus other siblings like search_companies or get_company. The guidance is useful but lacks a broader decision tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
County figures, or every county when county is omitted: medians, employment, and aid. Use sector_stats when the question is an EMTAK rather than a place.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year | |
| county | No | County name or alias. Omit for every county. Valid: Ida-Viru maakond, Lääne-Viru maakond, Harju maakond, Hiiu maakond, Jõgeva maakond, Järva maakond, Lääne maakond, Põlva maakond, Pärnu maakond, Rapla maakond, Saare maakond, Tartu maakond, Valga maakond, Viljandi maakond, Võru maakond, Maakond puudu. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: it returns aggregated county-level statistics and treats a missing county as 'all counties.' It does not detail response shape, but that is not critical for a read-only stats tool with no output 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 with no filler. The core behavior is front-loaded, and the alternative tool guidance is placed in the second sentence without unnecessary explanation.
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 two-parameter, read-only statistics tool with full schema coverage and a clear sibling reference, the description is complete. An agent has enough context to select the tool, know when to use it, and understand the effect of omitting county.
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 schema already documents both year and county parameters. The description reinforces the 'omit county for all counties' behavior but does not add meaningful parameter detail beyond what the schema provides. 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 states a specific resource ('county figures') and the data categories it returns (medians, employment, aid), and explicitly distinguishes itself from sector_stats by geography vs. EMTAK. An agent can immediately tell what this tool does and how it differs from its closest sibling.
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 explicit routing guidance: use sector_stats when the question concerns an EMTAK rather than a place. It also clarifies the default behavior when county is omitted, which is essential for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Companies that currently match one register signal: tax debt, bankruptcy, liquidation, or distress. Each row is a company, not a person. Opaque cursor pagination. Use check_counterparty for one known registry code.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | tax_debt, bankruptcy, liquidation, distress_high, or distress_moderate | |
| emtak | No | EMTAK code or prefix | |
| limit | No | At most 25 signals | |
| county | No | County name or alias. Valid: Ida-Viru maakond, Lääne-Viru maakond, Harju maakond, Hiiu maakond, Jõgeva maakond, Järva maakond, Lääne maakond, Põlva maakond, Pärnu maakond, Rapla maakond, Saare maakond, Tartu maakond, Valga maakond, Viljandi maakond, Võru maakond, Maakond puudu. | |
| cursor | No | Opaque cursor from a previous next_cursor for the next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only and non-destructive annotations already cover safety. The description adds valuable behavioral context beyond annotations: 'Opaque cursor pagination' warns the agent that pagination is required and cursor-based, and the row-granularity note prevents assuming the data concerns people. No mention of rate limits or auth, but annotations reduce the burden.
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?
Four short sentences, each earning its place: core purpose, row granularity, pagination behavior, and the key sibling alternative. The most important 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?
Given the 100% schema coverage and safety annotations, the description covers the essential non-obvious aspects: pagination and the correct single-lookup alternative. Without an output schema, it could say a bit more about the result shape, but 'Companies that currently match' adequately conveys the return type.
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 schema fully documents kind, emtak, limit, county, and cursor. The description does not add semantic detail beyond the schema—it even omits the distress_high/distress_moderate distinction by saying only 'distress'—so it provides minimal additional parameter value.
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 resource: companies that currently match one register signal, and enumerates the signal types. It also differentiates from the sibling check_counterparty by implication, though it lacks an explicit imperative verb like 'list' or 'search'.
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 names check_counterparty as the alternative for a single known registry code, which tells the agent when not to use this tool. Context about row granularity ('each row is a company, not a person') also helps avoid misuse, but no broader exclusions for other siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search active legal entities by current or former name or registry code. Use include_inactive for non-active statuses. County aliases accepted; unknown county errors. Opaque cursor pagination. Use this for a short list when you have a name or a code. Use get_company for one code's full card, and find_companies to filter by county, EMTAK, revenue, or employees.
| Name | Required | Description | Default |
|---|---|---|---|
| emtak | No | EMTAK code or prefix | |
| limit | No | At most 25 companies | |
| query | Yes | Company name or 8-digit registry code | |
| county | No | County name or alias (Harju, Harjumaa, Harju maakond). Valid: Ida-Viru maakond, Lääne-Viru maakond, Harju maakond, Hiiu maakond, Jõgeva maakond, Järva maakond, Lääne maakond, Põlva maakond, Pärnu maakond, Rapla maakond, Saare maakond, Tartu maakond, Valga maakond, Viljandi maakond, Võru maakond, Maakond puudu. | |
| cursor | No | Opaque cursor from a previous next_cursor for the next page | |
| include_inactive | No | Include liquidated, bankrupt, and deleted companies. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral details: it searches active entities by default, accepts county aliases (with errors for unknown counties), and uses opaque cursor pagination. This goes beyond annotations and helps the agent anticipate edge cases.
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 three sentences with zero filler. The primary purpose is front-loaded, followed by key behavioral notes and sibling differentiation. Every sentence earns its place, making it easy to scan.
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 6 parameters, no output schema, and annotations only cover safety, the description is remarkably complete. It covers the main use case, the default behavior, the inactive flag, pagination, and clear guidance on when to use sibling tools. Nothing essential for correct invocation is missing.
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 baseline is 3. The description adds value by explaining that county aliases are accepted and unknown counties produce errors, and that cursor pagination is opaque. These clarifications go beyond the schema descriptions, which simply list valid values or describe the cursor as 'opaque'. The mention of include_inactive aligns with the parameter but doesn't add extra semantics.
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 searches active legal entities by current or former name or registry code. It explicitly contrasts with sibling tools (get_company for full card, find_companies for filters), making the purpose unambiguous. The verb 'search' and resource 'legal entities' are specific.
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?
Explicitly states when to use this tool ('when you have a name or a code') and when to use alternatives (get_company for one code's full card, find_companies for filters). Also explains include_inactive for non-active statuses. This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sector medians, percentiles, and company counts for one EMTAK. Use region_stats when the question is a county rather than an industry, and compare_companies for named firms.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year | |
| emtak | Yes | EMTAK code or division | |
| county | No | County name or alias, optional. Valid: Ida-Viru maakond, Lääne-Viru maakond, Harju maakond, Hiiu maakond, Jõgeva maakond, Järva maakond, Lääne maakond, Põlva maakond, Pärnu maakond, Rapla maakond, Saare maakond, Tartu maakond, Valga maakond, Viljandi maakond, Võru maakond, Maakond puudu. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the single-EMTAK scope and the output metrics, but does not disclose behavior around the optional county filter (how it interacts with sector aggregation), the default year behavior (null meaning), or data coverage. With annotations doing the heavy lifting, the description adds modest but not rich context.
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 with zero filler: the first front-loads the core purpose and outputs, the second delivers the sibling routing. Every word 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?
Given no output schema and moderate parameter complexity, the description covers purpose and routing well, but it leaves the county parameter's role somewhat ambiguous given region_stats exists for counties — an agent may wonder when to supply county to sector_stats versus switching tools. Default-year behavior and aggregation scope are also undisclosed.
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 of 3 applies. The description confirms emtak is the primary sector filter but adds no meaning beyond the schema for the year or county parameters; it does not explain, for instance, what year=null means or how county filters the sector stats.
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 states a concrete resource (sector statistics for one EMTAK) and enumerates specific outputs (medians, percentiles, company counts), giving the agent a precise picture of what the tool returns. It also distinguishes itself from siblings by naming region_stats and compare_companies, so an agent can separate the tools without opening schemas.
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 second sentence gives explicit routing: use region_stats for county-level questions and compare_companies for named firms. This directly answers the when-to-use-this-vs-alternatives question and leaves nothing to inference.
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.
check_counterpartycompare_companiesfind_companiesget_companyopen_callsprocurement_noticesregion_statsrisk_signalssearch_companiessector_statsDanish company registry (CVR): company search, financials, ownership, beneficial owners and more.
Statistics Estonia (andmed.stat.ee) PxWeb MCP. Keyless.
Live data from 27 official national company registries. Unmodified. For KYB and due diligence.
Austria's official company register (Firmenbuch) – master data, financials & ratios for AI agents.
Add one secure layer between your agents and this server.
