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

Goes well beyond the annotations by disclosing the verdict taxonomy (PASS/FIX/BLOCK), the 0-100 score, the per-check result payload, and the exact PII severity thresholds (SSN/card → BLOCK, email → FIX, phone/IP flagged only). It also surfaces the important data-egress fact that model 'none' sends nothing externally and that the Groq review uses a server key, which is precisely the context openWorldHint alone cannot convey.

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?

Front-loaded with the purpose and verdicts, then check inventory, then the PII gating rule — every clause carries information. It is a single dense paragraph with nested parentheticals (checks.injection / checks.injection_prompt) that would read better split into a short purpose line plus behavior notes.

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 multi-check composite tool, the description covers what is evaluated, what comes back (verdict, score, per-check results, fixes), the PII thresholds that drive the verdict, and the external-call escape hatch. With annotations and an output schema present, nothing an agent needs to invoke it correctly 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%, so the baseline is 3; the description earns an extra point by explaining the consequence of the 'model' parameter ('none' skips the review and sends nothing out) rather than just listing model names, and by reinforcing that prompt is itself scanned for injection. It does not clarify the rule object shape beyond deferring to guardrail_test.

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?

States a specific verb and resource ('one-call safety gate for an LLM response') and enumerates the exact checks performed: grounding, injection on response and prompt, toxicity, PII, guardrail rules, quality, and LLM review. It is clearly the aggregate sibling of toxicity_scan, prompt_injection_scan, redact_pii and guardrail_test, and an agent can tell it apart without opening the schema.

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?

Gives concrete conditional guidance: pass the prompt 'whenever you have it', set model to 'none' to skip the external LLM review, and rules use the same format as guardrail_test. What is missing is an explicit statement that this replaces the individual scanners (toxicity_scan, prompt_injection_scan, redact_pii) and when to prefer those lighter tools instead.

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