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

Goes well beyond the annotations by disclosing the return value's nature (short-lived link, immutable snapshot of the CV as sent), the required account state, and a real side effect: opening the link the first time notifies the candidate, without naming the referrer. That side effect is exactly the context an agent needs given readOnlyHint=false, and it is not derivable from the structured fields.

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?

Three sentences, front-loaded with the access requirements, then the effect, then the caveat about the notification. No filler and nothing repeated from the schema or annotations.

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 single-parameter tool with an output schema and full annotation coverage, the description supplies everything else an agent needs: auth prerequisites, the claim precondition, the transient nature of the link, and the candidate-visible side effect.

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% and the single parameter is described as coming from list_referrer_requests, so the baseline is 3. The description adds a genuine semantic constraint beyond the schema: the request must be one this user has claimed, which narrows valid values in a way the schema does not.

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: returns a short-lived download link to the CV a candidate sent with a referral request, snapshotted at send time. This clearly distinguishes it from get_cv / list_my_cvs, which deal with the user's own CVs rather than a candidate's submitted document.

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 precondition plus a named sibling to run first ('Only for a request this user claimed (claim_referral_request first)'), and mentions the sign-in / verified-referrer-account requirement. What is missing is any steering away from cases where another tool (e.g. get_cv) would be the right choice, but the exclusions given are concrete.

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