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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: what the response contains (best matches with per-provider cited reasons, published fee, visa support, deposit terms) and a downstream BestEOR.co link for quotes — information no structured field supplies.

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?

Purpose comes first in a single tight sentence, followed by a return-value sentence. The second sentence is dense with a parenthetical list but every item is decision-relevant content about the output; only the 'where the reader can see every match' phrasing is slightly padded.

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?

With no output schema, the description carries return-value duty and discharges it well by describing matches, reasons, fees, visa support and the quote link. Minor gaps remain: ranking behavior, result-count limits, and what happens when no provider matches are not addressed.

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 all four parameters are already documented, including the enums and the employee default. The description names the same four criteria but adds no syntax or format detail beyond what the schema provides, making the baseline of 3 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?

A specific verb ('Find') plus a precisely scoped resource ('providers that fit one specific hire'), with the four matching dimensions enumerated so the agent knows exactly what inputs define the search. The singular-hire framing implicitly separates it from the compare/list siblings.

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 sketches the situation the tool serves (one hire, with country, hire type, team size, visa need), which lets an agent infer when to reach for it. But it never names compare_eor_providers, estimate_eor_cost or the list/get siblings, nor states when not to use this tool, so the routing decision is left to inference.

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