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

With no annotations, the description carries the burden and does disclose the payload contents (status, legal form, statutory bodies, stakeholders, successors, red flags) and the $0.25 USDC cost, which are real behavioral facts. It does not state read-only semantics explicitly, rate limits, auth requirements, or what happens when a name search matches multiple companies, so it is good but not complete.

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 definition is front-loaded with purpose, source, and keys, then the output fields and price. The field enumeration is long but each item is informative; there is no filler, though the block could be tightened slightly for scanability.

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 nine-parameter tool with zero schema descriptions and no output schema, the description is materially incomplete: seven parameters, including 'limit', are never explained, pagination/multi-match behavior is unaddressed, and output structure is conveyed only as a loose field list. It is enough to attempt the happy path with ico or name, but not enough to use the tool reliably across its full parameter surface.

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 explains only 'ico' (8 digits) and 'name', leaving q, sk, rpo, limit, ico_sk, number, and identifier entirely undocumented with 0% schema coverage. The format hint and examples for the two main parameters are useful, but the majority of the nine parameters give the agent no guidance on how to construct a correct call.

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 names a specific verb and resource ('Slovak company lookup via RPO'), the source registry (api.statistics.sk), the two lookup keys, and the returned data fields. The 'sk_' prefix and explicit 'Slovak' scope distinguish it from the many sibling country tools (cz_company, pl_company, uk_company) without needing to open any schema.

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 clearly says to look up a Slovak company by ICO (8 digits) or name and gives worked examples for both paths. It gives no explicit exclusions or signposting to alternatives such as company_full or kyb_report, so the agent must infer that this is the country-specific lookup rather than the aggregated company tools.

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