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

Annotations already declare readOnlyHint/openWorldHint=false/destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts the annotations cannot convey: the 3-call trial is granted once at signup and is not monthly, per-endpoint pricing (EUR 0.40 for /findings, EUR 2.00 for /run), and that this call itself is free.

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 purpose and decision guidance are front-loaded, and the pricing/trial details that follow are the reason to read further. Minor waste in the trailing 'Free (no charge).' fragment and inconsistent formatting keep it from 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?

With an output schema present, the description needn't describe return values, and it covers the remaining unknowns an agent needs: what is measured, the cost model, and the one-time trial rule. Nothing material is missing for correct invocation or interpretation.

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 tool takes zero parameters, so the baseline of 4 applies and the schema fully covers the empty argument object. Nothing in the description is needed to clarify inputs.

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 set ('Check API usage, free trial calls remaining and pre-paid balance'), which is immediately distinguishable from the KYB/findings/adverse-media siblings. An agent knows exactly what information this returns without opening the 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 gives explicit decision context: 'Useful for AI agents to decide whether the next call will be free, paid, or fail with insufficient balance.' That is a clear when-to-use trigger, though it names no alternatives or exclusions (e.g., no guidance on whether to cache the result).

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?

Beyond the annotations (readOnly/openWorld/non-destructive), the description discloses the source set, the 10-year lookback window, the cost per call and the free-trial quota — commercial and scope behavior the agent could not infer from structured fields. It also names the coverage boundary (no sanctions/PEP), preventing false assumptions of completeness.

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?

Front-loaded with the purpose and the exclusion, then sources, then cost, then args — a logical order with no filler sentences. The Args block is slightly redundant for a two-parameter tool, but it is genuinely compensating for an undocumented 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?

Annotations cover safety, an output schema covers return values, and the description adds scope, sources, lookback and pricing, so an agent has what it needs to call correctly. The only residual gap is how to interpret or act on borderline findings, which the output schema partly handles.

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 0%, so the description must carry the parameter burden, and it does explain both: company_name as the entity to screen and website as an accuracy aid. The guidance is functional but thin — it doesn't say what input format the website expects (full URL vs domain) or what happens when company_name is 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?

States a specific verb and resource ('Screen a company for negative news, complaints and bad reviews') and enumerates the concrete sources checked, so an agent knows exactly what evidence the tool gathers. It also explicitly separates itself from kyb_findings, making it distinguishable from its closest sibling without opening 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?

Gives an explicit exclusion plus a redirect: 'No sanctions/PEP screening: use kyb_findings for that,' which is exactly the when-not/alternative guidance an agent needs. The pricing note ('EUR 0.40 per call after the 3 free trial API calls') further informs the decision to invoke it.

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?

Annotations already declare readOnly/destructive=false, so the safety profile is covered; the description adds genuinely new behavior: no charge, typical 60-180s completion, and that a compact summary is returned only at status='completed'. It omits the set of possible status values, which would be the natural next disclosure for a polling 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?

Front-loaded with purpose, then timing/cost, then args — efficient and appropriately sized. Minor redundancy in "Free (no charge)" and the Args block restates the schema keys, but nothing is bloated.

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 lightweight read-only poll with an output schema (which relieves it of explaining return shape), the description covers cost, latency, and both parameters. Only the status lifecycle (what values exist, which are terminal) is missing for full completeness.

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 0%, so the description must carry the load and largely does: run_id is identified as coming from kyb_run_submit, and agent_type's accepted values ("kyb-diligence", "adverse-media") are supplied even though the schema has no enum. It doesn't explain what agent_type changes in the response or whether it must match the original submission.

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?

States a specific verb (poll) and resource (status of an async report) and ties it directly to the producing tool, kyb_run_submit. An agent can distinguish this from kyb_findings/adverse_media, which retrieve results rather than poll submission state.

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?

Makes the usage context explicit: only for runs submitted via kyb_run_submit, and gives the expected wait window (60-180s) that governs polling. It does not name when to stop polling or point to the sibling result tools once status is completed, so it stops short of full routing guidance.

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?

Beyond the readOnly/openWorld annotations, it discloses latency (30-90s synchronous), pricing (EUR 0.40/call after 3 free trial calls), that no AI-written summary is produced, and the exact finding categories returned with source links. That cost and timing profile is precisely the operational context an agent needs before invoking a paid external call.

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?

Front-loaded with the action, then the returned findings, then operational facts (latency, price), then Args. Each block adds distinct information with no filler or repetition of the 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 paid external lookup with an output schema already covering return shape, the description supplies everything else an agent needs: what is checked, expected duration, cost model, trial allowance, and both parameter meanings. Nothing material is left ambiguous.

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 0%, so the description carries the burden and it does: it labels company_name as the legal name with a concrete example ("Tesco PLC") and explains website's purpose as disambiguation plus that it is strongly recommended. It stops short of specifying accepted URL formats or what happens if a wrong-name match occurs, which keeps it from a 5.

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?

States a specific verb and resource ("Run a fast KYB check on a company") and enumerates exactly what the check produces (registry record, sanctions/PEP, ICIJ, regulatory registers, adverse media). The word "Synchronous" plus the per-call pricing signals that this is the direct-run tool rather than the async sibling kyb_run_submit, so an agent can separate them without opening either 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 implies usage (a company lookup with a legal name and an optional disambiguating website, "strongly recommended") but never says when to pick this over kyb_run_submit or check_report_status, and there are no exclusions. The trial/quota note hints at cost-sensitive routing but leaves the sibling choice to inference.

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?

Beyond the annotations (readOnly=false, openWorld=true, destructive=false), the description discloses the async contract, the 1-3 minute polling latency, and per-call billing — real behavioral traits the annotations do not carry. It doesn't say whether a failed run is charged or how long run_ids stay valid, which keeps it from a 5.

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?

Front-loads the action and the async/polling contract before listing args, and every sentence carries information. The docstring-style 'Args:' block is slightly redundant formatting but not wasteful.

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?

Even though an output schema exists, the description usefully previews the report contents (verdicts, risk flags, summary, next steps) and completes the async workflow picture with the polling step. An agent has everything needed to call it and handle the result 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 0%, so the description must compensate, and it does document both parameters: company_name as 'Legal name' and website as the URL, plus the useful qualifier 'strongly recommended' for a parameter that is optional with an empty-string default. Only minor format guidance (e.g., scheme/domain expectations) is missing.

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?

States a specific verb+resource ('Submit a full KYB due-diligence report') and immediately marks it async. It also distinguishes itself from the sibling kyb_findings by explaining the report contains 'everything kyb_findings returns plus' verdicts, so an agent can tell the two apart without opening either 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?

Explicitly routes follow-up behavior: 'Poll with check_report_status after 1-3 minutes', naming the alternative tool and the timing condition. It also discloses the pricing gate (EUR 2.00 per call after 3 free trial calls), which tells the agent when the call is costly to invoke.

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