Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure, and it does so well. It warns that totals are capped at 5000 and that `pagination.isCapped` indicates truncation, and it explains that keys in `data.unknownFilters` were dropped, making results broader than requested. These are non-obvious behaviors that materially affect correct interpretation of results.

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 compact and front-loaded: the first clause states the purpose, then each subsequent sentence adds a critical operational caveat (cap, unknown filters, usage example). There is no redundant or filler content; every 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?

Given the tool's high complexity (58 parameters, no annotations, no output schema), the description provides a strong broad overview and the most critical runtime caveats. It doesn't spell out every pagination mechanism or filter-combination rule, but the schema fills many gaps, making this sufficiently complete for a complex search tool.

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 description adds only high-level parameter context, such as the `tech=` example and the analyst-style query pattern. With 58 parameters and 67% schema description coverage, the schema carries most of the parameter semantics; the description does not systematically compensate for the undocumented remainder, so this is adequate but not exceptional.

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 and resource: 'Structured multi-filter company search' across a detailed list of dimensions (registry, geography, sector, size, financials, credit/distress, sanctions, NIS2, cyber, digital footprint, public money). It also states the return shape (paginated list, per-country breakdown) and gives a concrete example query, making it unmistakable what this tool does and how it differs from simpler sibling search tools.

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 use case: 'Use for analyst-style queries like...' and provides a concrete multi-filter example. However, it does not explicitly say when NOT to use this tool or mention alternative sibling tools such as search_companies, so it lacks the when-not/alternatives element needed for a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It reveals the public route, authentication via MCP client, and geographical limitation. It also lists the exact registries checked, providing useful operational context beyond 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?

Three sentences: first states the core purpose, second explains auth behavior, third gives market scope. Everything earns its place with no redundancy or fluff.

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 provides a thorough list of check types, geographical scope, and authentication behavior. Despite lacking an output schema, it gives a strong sense of what the tool returns. Minor gaps include error handling and return format, but for a single-param tool this is quite 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?

Schema coverage is 100% for the single 'ico' parameter, which already includes detailed constraints (6-8 digits, pattern, market limitation). The description adds no param-specific details, so 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 clearly states it performs a compliance check for a Slovak company and enumerates specific data sources (AML/sanctions, debtor lists, insolvency, RPVS, regulatory flags). This distinguishes it from sibling tools like search_companies or get_financials, which serve different purposes.

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 provides explicit usage context: SK-only, public route with no server-side API key but routed through authenticated client, and notes CZ/AT are not yet available. It doesn't explicitly name alternatives, but the domain (compliance vs. search/details) makes the when-to-use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral transparency burden. It discloses the data source (SK CRZ), return fields, and a data quality caveat ('CPV code where available'). It also honestly limits scope to SK. It does not mention pagination or error behavior, but these are covered by the schema, and the tool is clearly a read-only listing.

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 moderately long but front-loaded with the core action and resource. The additional sentences about data source, scope, and use case are valuable and not redundant. It could be slightly tighter, but 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?

There is no output schema, so the description enumerates returned fields (contract value, buyer, signing date, subject, CPV) and provides business context. It also mentions the data source and geographic limitation, giving an agent enough context to invoke correctly. A minor gap is that it does not explicitly state the input ICO is the supplier, though that is strongly implied.

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% with detailed parameter descriptions (e.g., ICO format, limit cap, years example). The description adds no parameter-specific meaning beyond output expectations, so the baseline of 3 is appropriate. It does not need to repeat what the schema already 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 uses the specific verb 'List' with a clear resource ('public-sector contracts') and relationship ('where the given company is the supplier'). It distinguishes itself from siblings by explicitly stating it is SK-only and referencing the planned TED-search tool for broader EU coverage, making its purpose unique.

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 usage guidance: for B2G exposure analysis and supplier due diligence. It also gives an explicit exclusion: for broader EU procurement signal, use the planned TED-search tool (not yet exposed), and notes the SK-only limitation, which helps an agent decide when not to choose this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the disclosure burden. It reveals a specific behavioral quirk: 'For SK↔CZ 8-digit collisions the API picks the active SK match first' – useful non-obvious information. It does not mention error handling, rate limits, or explicitly state read-only, but the 'Fetch' verb and output list imply a safe read operation. The disclosed collision behavior goes beyond typical descriptions.

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, tightly packed with essential information. The first sentence front-loads the main action and output scope; the second addresses an important caveat. No filler or redundant wording.

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?

Despite no output schema, the description comprehensively lists the categories of data returned (identity, address, NACE, finances, tech signals, security, NIS2, sanctions, credit), giving the agent a clear picture of what to expect. It also covers the disambiguation context. For a read operation with good parameter schema, this is complete enough for effective 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 coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds value by explaining the purpose of 'country' in disambiguating 8-digit IČO collisions and noting it is required for non-SK/CZ identifiers, complementing the schema's field-level descriptions.

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 + resource: 'Fetch the full company profile by IČO' and enumerates exactly what is returned (identity, registered address, NACE, legal form, status, latest financials, tech stock/website/SSL signals, security findings, NIS2 scope, sanctions hits, credit score). It explicitly contrasts with sibling 'lookup_company (which is identity-only)', clearly distinguishing its scope.

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 provides explicit when-to-use guidance by stating it is 'Richer than lookup_company' and directly advises using 'lookup_company with explicit country for deterministic disambiguation' when SK↔CZ collisions occur. This tells the agent exactly when to prefer which tool, including an alternative for a specific edge case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the empty-result semantics (not isolated), the FO gate requirement for sole traders, bearer-auth requirement, and the walkable graph structure. This gives agents a realistic behavioral model.

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 detailed yet each sentence serves a purpose: functionality, usage, edge-case semantics, alternative guidance, and auth. Front-loaded with the core purpose and progressively adds nuance. No fluff.

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 complex graph-traversal tool with no output schema, the description covers return value structure, pagination-walkability, edge cases, and auth constraints. It is self-contained enough for an agent to use it correctly and know when to switch to another tool.

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?

Even though the schema covers 100% of parameters, the description adds context beyond the schema for the 'purpose' parameter (only needed for natural-person sole traders, ignored for legal entities, marketing/prospection invalid). It also reinforces the 'ico' constraint about markets keyed on legacy IČO.

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: it builds a company-to-company network via shared officers/shareholders. It differentiates from siblings by explicitly positioning it as the 'primary network-walk primitive' and references get_company_relations for alternative edge types (UBO/M&A).

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 explicit when-to-use and alternatives: 'feed a returned IČO back into get_company_network to traverse another hop' and 'try get_company_relations for UBO / M&A edges'. Also clarifies the empty-result case with guidance to try another tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries the behavioral burden. It discloses auth requirements (Bearer-auth + FO-gated), the refusal for sole traders without FO addendum, the minimization of UBO data (birth year only), the legacy IČO keying limitation, and the public-official flag. This goes well beyond what annotations would typically 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 a single dense paragraph, but every sentence contributes (content list, sibling differentiation, auth/limitation notes). It is longer than ideal but appropriately packed for a tool with this complexity. Slightly better structure (e.g., bullets) would make it a 5.

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?

Despite no output schema, the description enumerates all return components (officers, UBO with validity windows, related companies, corporate shareholders with IČO resolution, M&A events). It also covers limitations, auth context, and parameter usage. This is complete 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 coverage is 100%, so the baseline is 3. The description adds meaningful context: purpose is 'only needed for full-tier keys when the subject is a natural person', 'ignored for legal entities', and the IČO limitation is reiterated. This adds practical usage nuance beyond the schema definitions.

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 opens with 'Full relationship graph for one company' and enumerates exactly what is included (directors, shareholders, UBO, related companies, corporate shareholders, M&A events). It also explicitly contrasts with get_company_network, making the specific scope unmistakable.

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 explicit guidance: 'Use get_company_network to walk company→company hops, use this to enumerate a single company's owners and officers.' It also states when the endpoint is not reachable (non-IČO markets) and the FO-gated auth conditions, clearly indicating appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the data source per jurisdiction, that amounts are in EUR with a `unit` field, that ROA/ROE are ratios, and that it is an extractor over get_company_details. It does not discuss error handling or missing data scenarios, but the core behavioral context is well covered.

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, front-loaded with the core purpose, followed by units/source and the implementation note. Every sentence earns its place and there is no redundant or verbose language.

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?

Despite lacking an output schema, the description fully explains what is returned (list of annual statements, specific financial metrics, units, ratios). Combined with the detailed parameter schema and clear sibling differentiation, the tool context is complete for effective selection and 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 per the rubric, the baseline is 3. The description adds no parameter-specific semantics beyond what the schema already provides; it only mentions jurisdiction in the context of the data source, not the parameter 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 uses a specific verb ('Return') and resource ('most-recent annual financial statements') and enumerates the exact fields (turnover, total assets, equity, profit, EBITDA, ROA, ROE). It also distinguishes itself from siblings by branding itself as a 'thin extractor over get_company_details', which clearly separates it from the broader lookup tools.

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 states when to use this tool: 'saves the LLM from parsing the full company envelope when only financials are needed.' It also names the alternative (get_company_details) and provides jurisdictional source guidance, making the use cases clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses that responses are cached for 15 minutes and are millisecond-fast, indicating potential staleness and performance characteristics. It does not explicitly state read-only nature, but 'fetch' and 'pre-computed' imply no side effects, and the enum constrains inputs. One minor gap is the lack of info on response format, but that is not critical given the tool's simplicity.

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, front-loaded with the action, then enumerates the slugs, and closes with a practical usage tip. Every sentence adds value with no fluff 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?

For a simple single-parameter tool with no output schema, the description fully covers purpose, usage, cache behavior, and even provides a rationale for its existence. It is complete enough for an agent to select and invoke this tool correctly without further clarification.

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%, with the 'key' parameter description already explaining each enum value fully. The tool description adds no additional parameter-level semantics beyond restating the same four slugs and adding context about the top-100 nature. This meets the baseline but does not exceed it.

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 fetches a pre-computed company leaderboard by slug, enumerating exactly four specific rankings. This distinguishes it from sibling search/lookup tools by highlighting that it serves pre-assembled top-N lists rather than arbitrary queries.

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 when to use this tool: for 'top 100 …' style queries the LLM would otherwise assemble from many advanced_search calls. It also lists the exact four valid slugs, providing clear alternatives with advanced_search and implicitly excluding other use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden and does so well: it reveals country-aware routing, support for multiple national ID formats, and a defined return type ('single company object with core identity, address, legal form, status flags'). It doesn't cover error/edge behavior, but the core behavior is transparent.

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, front-loaded with the main purpose, and every clause adds functional value—alternatives, shapes handled, and return contents. 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?

Despite no output schema, the description specifies what the returned object contains and covers the main complexity (different national ID shapes and country disambiguation). For a lookup tool, this is complete enough for an agent to confidently invoke 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 the schema already fully documents both parameters including format examples and the SK↔CZ collision issue. The description adds context about 'all our shapes' but largely repeats schema content. The baseline of 3 applies because the description doesn't significantly augment the schema.

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 opens with a specific action—'Resolve a single company by its national registry identifier'—and explicitly scopes the tool to country-disambiguated lookups by national ID. It also differentiates from sibling tools by contrasting with search_companies for name-based discovery.

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 when to use the tool: 'Use this when you already know the registry number'. It also gives an alternative: 'use search_companies for name-based discovery', which clearly directs the agent to the right sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It reveals typo-tolerance via autocomplete index, p95 latency, return fields, and market coverage. It does not explicitly state read-only status, but the tool name and 'search' semantics imply it.

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 four sentences, each providing distinct value: action, performance, return fields, use case, and coverage. It is front-loaded and free of filler, making it effectively concise.

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 no annotations, the description adequately covers the tool's scope and return fields. It could mention result structure or pagination, but it is otherwise complete for a search tool.

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% with each parameter described. The description adds slight context by mapping q to name/partial/address, but does not provide additional semantic detail for limit, country, or active_only beyond what the schema already offers.

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 European companies by name, partial name, or address. It distinguishes itself from sibling tools by targeting fuzzy queries and returning ranked hits with specific fields, while explicitly mentioning lookup_company and get_company_details for follow-up.

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?

Explicit guidance is provided: 'Use this for fuzzy find a company called… queries before drilling into details with lookup_company or get_company_details.' This gives both when to use and names alternatives, making the usage context very clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.