affirmation_random

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, and openWorld=true, so the safety profile is fully covered by structured fields. The description adds no further behavior — notably it does not mention that a remote API is involved despite openWorldHint, nor any latency/failure behavior — but it also contradicts nothing.

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?

A single short sentence, front-loaded with the verb and resource, with no filler. Nothing could be removed without losing meaning.

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 trivial read-only, zero-parameter call with no output schema, the description covers everything needed to invoke it. The only gap is not hinting that the return value is a random affirmation string (and that repeated calls yield different results despite idempotentHint).

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty with additionalProperties=false, matching the description's implication of a no-argument call.

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 gives a specific verb plus resource ('Get a random positive affirmation'), which is unambiguous and distinguishable from quote/zen_quote/dadjoke siblings by resource alone. It does not explicitly name an alternative, but none of the siblings overlap on this resource.

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?

Use case is only implied by the description text; there is no statement of when to prefer this over e.g. quote_random or zen_quote_random, nor any exclusion. For a zero-parameter novelty tool the implied usage is sufficient to act, which is the definition of a 3.

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