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

Annotations already declare a read-only, idempotent, non-destructive, non-open-world operation, and the description adds material context beyond that: the auth/verified-referrer gating, which fields are visible before versus after claim_referral_request, and the fact that candidate name, message and CV text are untrusted third-party data. That last point is a genuine safety signal an agent cannot get from 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?

The first sentence front-loads auth requirements and scope, and the remainder is information-dense with little waste. It is a long, run-on block of sentences where the field-visibility and untrusted-data points could be split more cleanly, and the UI-location sentence is of marginal value, but nothing is filler.

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?

The tool has an output schema, so return shape needn't be described, and everything else an agent needs is present: auth gating, default vs filtered behavior, the claim-gated fields, a cross-reference to the sibling for the inverse inbox, and a data-provenance warning. Nothing required for correct invocation is missing.

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 100% and the status enum is already fully documented in the schema, including the 'new' = open/unclaimed mapping and the omit-for-full-inbox behavior. The description's mention of 'open requests the candidate chose them for, plus the ones they claimed or handled' reinforces the default but adds no new filter semantics beyond the schema, so baseline 3 applies.

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 (lists referral requests) plus the exact scope: requests candidates sent to the signed-in user as a referrer. It also explicitly separates this from list_referral_requests, which covers requests the user sent as a candidate, so an agent can route between the two without opening a 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?

Names prerequisites (techjobs.vn sign-in, verified referrer account), gives the when-to-use boundary versus the sibling list_referral_requests, and points to claim_referral_request as the follow-up that unlocks candidate identity. It even notes the UI location (Referrer → Request cho bạn), which is unusual but confirms the scope.

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