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

Annotations only cover safety and idempotency flags, so the description carries real weight and delivers: no API key, account, or sign-up required, and a hard 24-hour expiry that the agent cannot infer from annotations. It does not restate that each call produces a distinct link (non-idempotent), but that is already declared by idempotentHint=false, so the omission is minor rather than a contradiction.

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, all front-loaded: what it does, when to reach for it, then the critical expiry caveat. Every clause earns its place, including the list of use cases, which is what makes the trigger conditions actionable.

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 is simple, has an output schema, and full schema coverage for its one parameter, so the description only needs to add auth model and lifetime semantics, both of which it covers. An agent has everything required to invoke it correctly and to know when the result will stop working.

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 single parameter is fully described in the schema (format uri, maxLength 4096, 'HTTP or HTTPS URL to shorten'), so the baseline applies. The description adds no syntax or format guidance beyond that; it never mentions the 4096 limit or that non-HTTP schemes are rejected.

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 first sentence gives a concrete verb and artifact: turn a long URL into a short 307.fi link that redirects to it. That names the input, the output domain, and the redirect behavior, which is enough to distinguish it from anything else in the sibling list (closest neighbors, create_qr_code and slugify_text, do not shorten URLs).

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 explicit positive triggers (typed, read aloud, pasted into a length-limited message, shown to a person) and an explicit exclusion (nothing that must survive longer than a day, not for publishing). It also names the intended scope, handoffs inside a task, which resolves the main ambiguity an agent would face.

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