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

With no annotations, the description carries the full burden and does disclose several real behavioral traits: the upstream source, the CC BY 4.0 license, the returned field set, and a per-call cost of $0.25 USDC — the pricing detail is especially valuable for an agent deciding whether to call. It stops short of describing response shape, error/not-found behavior, or match-fuzziness for name searches.

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 dense and front-loaded: source and jurisdiction first, then returned fields, then search keys, then example, then price. Every element carries information; the only mild bloat is the long comma-separated field list, though that list substitutes for the absent output schema.

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 seven-parameter tool with zero schema description coverage, no annotations, and no output schema, the description does useful work by enumerating returned fields, the data source, and cost. It is still incomplete: three parameters (q, limit, number) are unexplained, and there is no guidance on pagination or result limits despite a 'limit' parameter existing.

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 0%, so the description must compensate. It identifies four of the seven parameters (businessId, ytunnus, fi, name) and supplies an example value that reveals the Y-tunnus format, but q, limit, and number are entirely undocumented in both schema and description, and the distinction between the three identifier aliases (businessId/ytunnus/fi) is left ambiguous.

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 concrete verb and resource ('Finnish company lookup') plus the data source (PRH YTJ open data) and enumerates the fields returned (name, Y-tunnus, status, form, address, business line, website, situations, red flags). The jurisdiction qualifier implicitly distinguishes it from siblings like uk_company or au_company, but it never explicitly contrasts with broader siblings such as company_full, company_research, or kyb_report.

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 gives the accepted search keys and a worked example ('{businessId:"0112038-9"}'), which implies the intended usage of a single-company lookup. However, there is no statement of when to prefer it over company_full, company_research, or kyb_report, and no note on what happens when a search returns nothing.

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