OnceAsk

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds a non-obvious privacy guarantee ('Does not expose recipient address data'), which is valuable context not derivable from the annotations alone.

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?

Two sentences with no filler: the first states purpose, the second states an important behavioral limitation. Front-loaded and every sentence earns its place.

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 parameterless listing tool with read-only annotations and no output schema, the description covers all necessary information: what it lists, why it is safe, and what data it does not expose. Nothing an agent needs to invoke it correctly 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?

The tool has zero parameters, so the schema fully covers parameter semantics. Baseline for 0-parameter tools is 4, and the description appropriately does not invent parameter-related content.

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 ('List') and resource ('Handwrytten card designs and handwriting styles'), and adds a functional scoping note ('privacy-preserving fulfillment'). This clearly differentiates the tool from siblings like send_handwritten_card, which would perform an actual send operation.

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 clearly implies the usage context—browsing available card designs and handwriting styles before fulfillment. However, it does not explicitly name sibling tools or state when not to use it, leaving some inference to the agent.

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?

The description discloses that OnceAsk searches contacts and connected Google/Gmail-derived people, emails the request when possible, and hides the recipient's email/street address from the agent. This adds meaningful behavioral context beyond the annotations, revealing both side effects and privacy boundaries.

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?

Two concise sentences front-load the key trigger ('After the user explicitly confirms') and then cover input modes, behavior, and privacy. Every clause adds information; there is no filler or redundant 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?

The description adequately covers the tool's purpose, prerequisites, input options, side effects, and privacy guarantees. It does not describe the return value or failure behavior, but given the absence of an output schema and the nature of the tool, this is a minor gap rather than a blocking omission.

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 the baseline is 3, but the description adds valuable cross-references: it maps query to 'person's name/email when recipientId is not known' and contactId to 'recipientId from resolve_delivery'. This clarifies when to use each parameter beyond the schema's standalone wording.

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 action ('request a current delivery address/permission') and the resource (OnceAsk), and clarifies it accepts either a recipientId or a name/email. It clearly differs from siblings like send_handwritten_card and resolve_delivery by focusing on the permission-gathering step.

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 states an explicit precondition ('After the user explicitly confirms they want the recipient contacted') and explains the two accepted input paths. It does not explicitly contrast with send_handwritten_card, but the workflow position is clear enough that an agent knows when to call this rather than the sibling send tool.

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 only provide generic hints (not read-only, not destructive), so the description carries the behavioral burden. It discloses meaningful traits: privacy-preserving behavior, search order, external data sources, success conditions, token lifetime, and that the street address is never returned. However, it does not clarify whether resolution has side effects such as consuming or generating a token beyond the single sentence.

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 description is compact and front-loaded with the key purpose, then packs search behavior, resolution conditions, and the privacy guarantee into efficient sentences. Every sentence adds substantive information without marketing fluff.

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 should explain what the agent can expect upon success or failure. It says it resolves to a token and does not return the street address, but it does not describe token format, error cases when permission or address is missing, or whether the caller should call request_delivery_permission first. Overall adequate but with clear gaps.

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 input schema covers all three parameters with descriptions, so the baseline is 3. The description adds high-level context about searching and resolving but does not explain parameter relationships or priorities beyond what the schema already says, such as when to use query versus contactId.

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 clearly states the tool resolves a person to a short-lived one-time delivery token and emphasizes privacy, which distinguishes it from sibling tools like send_handwritten_card and request_delivery_permission. However, the opening phrase 'way to send something to a person' slightly blurs the line between resolving and actually sending, so it is not fully precise.

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 implies usage context by noting it searches OnceAsk first, can discover missing people from Google Contacts or Gmail, and requires recipient permission and a current address. It does not explicitly contrast with sibling tools or state when to choose request_delivery_permission or send_handwritten_card instead, leaving the decision partly 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, the description discloses a non-obvious behavioral trait: the recipient address is sent directly to the fulfillment provider and is never visible to the agent. This adds meaningful privacy and side-effect context that the schema and annotations do not express.

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 description is only two sentences, with the core action stated first and the most valuable privacy detail second. Every sentence carries necessary information with no filler or repetition.

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 side-effecting tool with fully documented parameters and annotations signaling destructive/open-world behavior, the description covers the essential precondition (delivery token) and the address-handling nuance. It does not describe post-call confirmation, but no output schema exists and the tool's role as a terminal action is clear.

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 the baseline is 3, but the description adds important semantic context: it explains why no address parameter exists and clarifies that the delivery token is the handle for the out-of-band recipient address. This goes beyond the schema's per-parameter descriptions.

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 precise action ('Fulfill a handwritten card') and ties it to a concrete prerequisite ('using a delivery token returned by resolve_delivery'), which distinguishes it from the sibling tools. It is clearly the final send step rather than listing, permission, or delivery resolution.

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 explicitly indicates when this tool is appropriate: after resolve_delivery has produced the delivery token. It does not spell out when not to use it or mention the list/permission siblings, but the workflow context is strongly implied.

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