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

Annotations only declare readOnlyHint and openWorldHint; the description adds the material behavior: return shape (flagged boolean plus 0-1 score), a 30-per-day-per-network rate limit on the keyless public guard, the authenticated path with a request_id, and an explicit accuracy limitation. These are exactly the operational facts an agent needs before deciding to call it.

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, each carrying distinct load: purpose and return shape first, then auth/rate-limit behavior, then the scope caveat. No filler, and the most decision-relevant facts are front-loaded.

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?

There is no output schema, and the description compensates by naming the return fields (flagged, score, request_id). Given a one-parameter, read-only classifier, the description covers input scope, cost limits, auth paths, and known weakness — nothing an agent needs is missing.

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 100% and the sole parameter already documents the 8,000-character cap, so the schema does the heavy lifting. The description reinforces that the parameter must be a user prompt rather than arbitrary text, which is useful but adds only marginal meaning beyond the 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 opens with a specific question-shaped definition of the resource being classified ("user-typed text... prompt injection or jailbreak") and parenthetically defines what injection means. It is clearly distinguishable from siblings teach_guard (which trains the guard) and get_free_key (which obtains credentials).

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 the intended input domain ("Built for user prompts") and an explicit exclusion ("weak on injections hidden in tool output or documents"), which is genuine when-not guidance. It also implicitly routes key acquisition to the sibling by saying "With a key it uses your own guard, which learns from teach_guard," though it never says to call get_free_key first.

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