prompt_injection_jailbreak_classifier

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

No annotations are provided, so the description carries full burden. It does disclose 'high-speed deterministic classifier', which tells the agent the tool is deterministic and fast, and notes a 0.045 USDC cost on Base L2. However, it omits return format (what a classification result looks like), behavior when paymentSignature is absent, and error handling—gaps that matter for a paid tool with no output schema.

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?

Two sentences with the purpose front-loaded and the cost as a compact parenthetical. Every clause earns its place and there is no filler or repetition of schema content.

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 output schema, the description must explain what the classifier returns, and it does not—an agent cannot tell whether it gets a label, a confidence score, or a boolean. The payment flow is also ambiguous: the cost is stated but the schema marks paymentSignature optional, leaving unclear whether the tool executes without payment. These omissions leave an agent under-informed for a paid security tool.

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 description coverage is 100%, so baseline is 3. The description reinforces that payload is user input to be analyzed, but adds no format guidance (plain text vs JSON string) beyond the generic schema wording, and the paymentSignature semantics are only covered by the schema's boilerplate. The description does not meaningfully extend 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 uses a specific verb ('detecting') with a clear resource (prompt injection/jailbreak attacks) and enumerates three concrete attack types (indirect prompt injections, delimiter hijacking, system role impersonation). It distinguishes itself from the sibling strip_prompt_injection by being a classifier/detector rather than a sanitizer, so an agent can tell them apart from the description alone.

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 purpose implies when to use it (classify user inputs for injection attacks), but it never explicitly states when to prefer this over the sibling strip_prompt_injection (which removes rather than detects), nor does it give exclusion criteria or mention whether the payment requirement gates usage. The cost note is contextual but not a usage guideline.

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