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

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the description's added value is the privacy contract: it never collects ID numbers, bank details, or contact details, and never contacts anyone. It also discloses an internal side flow (the eligibility screen runs first). It stops short of describing size/latency or what happens when facts are missing.

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 deliverable is front-loaded in the first clause, followed by the secondary output (site-only fields, apply link) and the exclusion set. It is a single dense sentence whose only weakness is comma-chaining several distinct obligations that would read faster as separate sentences.

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 required parameters and an output schema present, the description does not need to explain return values, and it covers purpose, boundaries, and privacy well. What is missing for a 13-parameter tool at 0% schema coverage is any guidance on which facts are needed or how to behave when the conversation did not surface them.

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% across 13 parameters, so the description carries the full burden and largely does not meet it – none of notes, billing_model, processing_history, or the currency arrays are explained or given format expectations. The one useful hint is that these values are 'facts already discussed', i.e. drawn from prior conversation, and the exclusion of ID/bank/contact details signals what is deliberately absent, but that leaves eleven parameters undocumented.

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 states a specific verb and deliverable set: turn discussed business facts into copyable answers for PayFresco's application form, list site-only entries, and give the apply link. The negative scope ('Does not fill in, submit, or send an application') cleanly separates it from start_application, which an agent could otherwise confuse with this tool.

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 conveys the precondition clearly – use it once business facts have already been discussed – and gives explicit exclusions (no fill-in, no submission, no contact). 'Runs the same eligibility screen first' hints at overlap with check_eligibility, but no sibling is named as the alternative to pick instead, so routing at the boundary is implied rather than stated.

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