check_prompt_injection

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

Description discloses significant behavioral traits beyond annotations: the text is sent to the lovec.tech API (not local), each call spends one request against the key's balance, score is bimodal with mid-range as low-confidence, and there is a known false-positive tendency on long evaluative text. These details are critical for correct use and go far beyond the readOnlyHint and idempotentHint annotations. No contradiction exists.

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?

Every sentence earns its place: purpose, use cases, exclusions, external call, cost, score interpretation, and false-positive caveat. The description is front-loaded with the core action and then layers operational context without redundancy. It is appropriately detailed for the tool's complexity.

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 external API dependency, cost per call, and score interpretation nuances, the description covers all necessary aspects. It explains when to use, when not to, operational behavior, and known limitations. The output schema exists, so return values are not needed in the description. Nothing critical is missing for an agent to invoke it correctly.

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 input schema provides zero description coverage for the single 'text' parameter. The description compensates by labeling it as 'untrusted text' and clarifying its role as the content to be analyzed. It does not add format or length constraints, but for a single obvious parameter this is sufficient.

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?

Description opens with a specific verb and resource: 'Check a piece of untrusted text for prompt-injection risk.' It further clarifies the exact scope by listing sources (web page, document, tool result, email, review) and explicitly differentiates from RBAC and jailbreak filtering. Even without siblings, the purpose is unambiguous and complete.

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?

Provides explicit when-to-use guidance: any content handed to another LLM that did not originate from the trusted user. Also states clear exclusions: it does NOT enforce authorization/RBAC and is not a jailbreak filter for the user's own messages. This gives an agent precise criteria for invoking the tool versus alternatives.

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