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

Annotations cover only safety hints (readOnly, openWorld, non-idempotent), while the description supplies the behavior that actually matters: the payload is delivered to the owner's email, never returns to the caller, the link lives 24 hours behind a browser identity confirmation, and the limit is 5/day with a 429 + retryAt on the sixth. It also explains why idempotentHint=false is true in practice.

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?

It is one dense paragraph but front-loaded with the purpose, and nearly every clause carries operational weight (delivery target, expiry, rate limit, follow-up instruction). The parenthetical inventory of exported entities is long but legitimately scopes the request.

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 input params and no output schema, the description must carry the full load, and it does: it explains what is exported, where it goes, what the caller receives back, how long the link lasts, and how to handle the rate limit. An agent can call this and interpret the result without any other source.

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?

With zero input parameters the baseline is 4, and there is nothing to disambiguate. The description goes further by documenting the three response fields (sentTo masked, expiresAt, relay message), which substitutes for the absent output schema rather than the input schema.

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 resource ('Email the owner a link to download a full copy of their Daycal data') and enumerates exactly what the export contains. It is unmistakably distinct from every sibling, all of which are list_/get_ readers that return data to the caller.

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 gives an explicit trigger ('Call it when the owner asks for their data'), an explicit follow-up ('then tell them to check their email'), and an explicit when-not ('ask again only if the owner lost the email'), plus the rate-limit path. No alternative tool competes for this job, so nothing is left to inference.

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