random_ascii

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

With no annotations, the description carries full behavioral disclosure burden. It only states what it returns, not any side effects (though likely read-only), determinism, or failure modes. It doesn't mention if the result could be empty, or whether the filter restricts the random pool. Minimal behavioral insight beyond the immediate action.

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 a single, efficient sentence. It packs the core information (random + optional filter) without wasted words. Perfectly sized for a simple tool.

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?

Given the tool's low complexity (1 optional param, no output schema, no annotations), the description is minimally complete. It states what it returns and how to filter. However, it lacks context on when to use this vs siblings, and does not indicate if the selection is truly uniform or if there are any edge cases (e.g., empty category). For a straightforward read-only tool, it's adequate but not thorough.

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 schema defines 'tipo' as an enum (ascii/unicode), so baseline is 3 due to schema coverage. The description adds the meaning that it acts as a filter ('optionally filtered by tipo'), which is useful. However, it doesn't elaborate beyond that—no format details or examples, so it neither fully compensates for the 0% schema description coverage nor adds substantial extra meaning.

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's action (return a random art entry) and identifies the resource (ASCII/Unicode art) with an optional filter. It inherently distinguishes from siblings like get_ascii_art (specific retrieval) and search_ascii (filtered search) by emphasizing randomness. The verb 'Return' is explicit and the scope is well-defined.

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 for obtaining a random art entry, but does not explicitly compare to alternatives or state when not to use it. There is no mention of when to prefer this over search_ascii or get_ascii_art. It provides a clear context (random selection) but no exclusions or contrast with sibling tools.

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