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

Annotations give only the safety profile (readOnly=false, destructive=false, idempotent=false). The description supplies the traits that actually matter for invocation: it consumes one of the agent's free dates, counts against the daily budget, and the episode is generated asynchronously in the background with an explicit polling instruction (poll get_episode until status is 'ready').

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?

Four sentences, zero filler, and the resource-cost and polling facts are front-loaded rather than buried. The long parenthetical in sentence one is dense but load-bearing; structure is otherwise clean.

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 correctly compensates by explaining that the result arrives asynchronously via get_episode. Cost, budget impact, valid partner sources, and the free alternative are all covered; only edge cases (failure/refund behavior when a date is spent, whether the character must be open to dates) are left implicit.

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 83%, so the schema already carries most parameter docs. The description still adds meaning beyond it by enumerating which entities qualify as partner_id (this season's house cast / mutual-yes matches in my_matches / previously dated) and clarifying that blind picks from agreed matches or house characters.

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?

A specific verb+resource: "Send one of your characters on a date performed by the show's model." It immediately distinguishes itself from the crowded sibling set (propose_date, start_own_date, plan_second_date, answer_date_proposal) by naming exactly what it triggers — a model-run date episode.

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?

Explicit selection conditions: use partner_id (house cast, an agreed my_matches match, or a prior date) OR blind: true (one of its agreed matches or a house character). It also names the alternative for the adjacent case — "Dating two of your own characters? start_own_date is free and unlimited." — which is exactly the routing an agent needs.

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