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

With no annotations, the description carries the full behavioral burden and leaves the most important trait ambiguous: 'to trip a circuit breaker' could mean it actually halts execution (a side-effecting action) or merely returns a recommendation. It also omits thresholds, cost, and whether anything is mutated. This ambiguity matters a lot for a breaker-style tool.

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?

A single dense sentence with the purpose and the detection targets front-loaded and no wasted words. It loses a point only because cramming three detection cases into one clause makes the conditions slightly harder to parse than separate sentences would.

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?

No annotations, no output schema, an undocumented parameter structure, and unresolved ambiguity about whether the tool acts or advises. For a tool whose whole purpose is to make a stop/continue decision on an agent loop, the description leaves critical operational details unaddressed.

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 0% and there is one required parameter, 'recent_action_trace'. The description's mention of 'recent tool-call traces' loosely maps to it, but the shape of the array items (untyped objects) and the expected trace fields are documented nowhere in either schema or description.

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?

Names a specific verb ('Analyzes') and resource ('recent tool-call traces') and enumerates its detection targets: cyclic retries, A/B deadlocks, runaway token burn. That is enough to distinguish it from the sibling firewalls (scrub_pii_firewall, tool_output_firewall) and guards, though it never explicitly names an alternative to route away from.

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 gives no when-to-use guidance, no prerequisites, and no exclusions. It does not say whether this should be called before or after a suspicious loop, or how it relates to guardrail_verify or mcp_sampling_guard. Usage must be inferred entirely from the name.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: the environment is ephemeral (no persisted state) and code is statically audited before running, implying unsafe code may be rejected. However, it omits timeouts, resource/network limits, what happens on audit failure, and the return format.

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?

A single front-loaded sentence that states the action, the input, and the two key mechanisms with zero filler. Every clause earns its place.

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 tool that executes untrusted code with no annotations and no output schema, the description should cover return values and sandbox limits. It conveys the isolation and auditing model but leaves execution constraints and result shape unspecified, which matters for a security-sensitive executor.

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% for the single 'code' parameter, whose schema description ('Python code to audit and run') already matches the description's mention of Python snippets. Baseline 3 applies since the description adds no syntax, format, or constraint details 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 names a specific verb and resource ('Executes untrusted Python snippets') plus the mechanism ('ephemeral sandbox with static AST safety auditing'). It is clearly distinguishable from sibling tools like sql_injection_ast_guard, but it never explicitly contrasts itself with them.

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?

There is no statement of when to reach for this tool versus alternatives such as sql_injection_ast_guard or guardrail_verify, and no preconditions (e.g., code size limits, supported imports) are given. Usage is only inferable from the stated purpose.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it leaves the critical behavior undefined: what does the gate return (verdict, boolean, exception), does a detection block execution, and is this a read-only inspection? It only implies inspection happens before execution, without stating enforcement semantics.

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?

A single tight sentence with the operative concept (pre-execution gate) front-loaded and the detection scope enumerated compactly. No filler.

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 no annotations, so the description should explain what the tool returns and how the agent should react to a detection. It is silent on both, leaving a real gap for a security gate whose entire value is the verdict it produces.

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%, with both parameters (payload, action_type) documented in the schema, so the baseline is 3. The description adds no detail about payload format, size limits, or the accepted values of action_type beyond "bash, tool_call".

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 states a specific role (pre-execution security gate) and enumerates the four threat classes it detects (prompt injection, destructive bash, wallet drain, key exfiltration). This clearly separates it from siblings like sql_injection_ast_guard and scrub_pii_firewall, though it never names those alternatives explicitly.

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?

"Pre-execution" implies the timing (call before running the payload), which is a useful contextual cue. However, there is no guidance on when to skip it, how it relates to the other guard tools, or what the agent should do with a negative result.

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

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

No annotations and no output schema, so the description carries the full disclosure burden. It states what is detected but not what happens on detection (block, warn, return a diff?), whether it is read-only, or how the required baseline/current inputs relate. Only the threat taxonomy is disclosed.

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?

A single front-loaded sentence with no filler, and the key detection targets lead the statement. It is tight, though its brevity is partly a symptom of under-specification rather than disciplined editing.

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 two-required-parameter tool with zero schema descriptions, no annotations, and no output schema, the definition omits input format, return/behavior semantics, and usage timing. It is too thin to invoke confidently without inspecting the schema or source.

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 0% for both required array parameters. The description provides no compensating detail about input format, expected shape of tool-list entries, or how baseline and current lists are compared, leaving the agent to infer everything from parameter names alone.

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 names a specific verb ('Detects') and three concrete failure modes: tools/list rug-pulls, shadow parameter injections, and coercive description mutations. That is enough to distinguish it from guard siblings like tool_output_firewall or mcp_sampling_guard, though it never explicitly contrasts itself with them.

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?

There is no when-to-use guidance, no prerequisites, and no alternatives named. 'Mid-session' weakly implies it is run during an active session against a prior listing, but the agent must infer both the timing and whether this is a blocking check or an advisory report.

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

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

With no annotations, the description carries the full burden. It usefully discloses the detection targets (systemPrompt hijacking, recursive quota drain), but says nothing about what happens on a match, whether the request is blocked or rewritten, or whether the call has side effects — all material for a security guard.

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?

A single front-loaded sentence with zero filler; the purpose and threat model land immediately. It is arguably too terse for a guard with an opaque nested payload, but there is no wasted language.

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?

No output schema, no annotations, and an undocumented nested object parameter. The description never explains the return contract (allow/deny verdict, modified request, reason codes), which an agent must know to act on the result of a security check.

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?

There is one nested object parameter at 0% schema description coverage, so the schema does not explain it. The description partially compensates by identifying the payload as an MCP sampling/createMessage request, but it does not state the expected shape, required fields, or whether the raw request is passed through verbatim.

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 gives a specific verb ('audits') and a precise resource ('inbound MCP sampling/createMessage requests'), plus the threat classes it targets. That is enough for an agent to distinguish it from generic siblings like guardrail_verify or tool_output_firewall, though it never names a sibling explicitly.

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?

Usage is implied by the object of the audit: this is the tool to invoke on an inbound sampling/createMessage request. There is no explicit when-to-use statement, no when-not, and no routing guidance relative to guardrail_verify, so the agent must infer placement in the request pipeline.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the detection scope (five named PII classes), which is genuine context, but it omits the safety profile: whether redaction is reversible, what the tool returns, whether the original text is mutated or a copy returned, and failure behavior on malformed input.

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?

A single sentence, front-loaded with the verb and the full entity list, with zero filler. Every clause earns its place and nothing is repeated from the schema or name.

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 simple one-parameter, no-output-schema tool this is close to adequate, but as an unannotated mutation-style operation it should clarify the return value and whether the input is modified in place. The minimum needed to call it correctly is present, yet the behavioral picture is thin.

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% with a single well-described parameter ("Raw text to scrub"), so the baseline is 3. The description elaborates on what within that text gets removed, adding small value, but contributes no format, size, or encoding guidance 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?

States a specific verb (redacts) plus the exact entity classes it targets (emails, SSNs, phone numbers, API keys, seed phrases) and the trigger context (before external LLM calls). This is far more informative than the name alone and clearly separates it from siblings like tool_output_firewall or guardrail_verify, though it never names those siblings explicitly.

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?

"before external LLM calls" implies the moment of use, which is real guidance, but there is no explicit when-not-to-use and no named alternative such as tool_output_firewall or guardrail_verify. Usage is inferred rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the mechanism (static, AST-based) and the failure classes it intercepts, but omits critical operational behavior: what happens when a query is flagged (reject, error, or boolean), whether the check is deterministic, and any dialect or configuration dependency.

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?

One dense, well-front-loaded sentence with no filler; the verb and mechanism lead, and every clause carries information. Slightly jargon-heavy but structurally efficient.

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?

No output schema exists, so the description should hint at the return shape (e.g., pass/fail plus reason). It instead stops at the detection categories, leaving an agent unable to predict the result of a flagged query — a meaningful gap for a guardrail 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?

The single parameter is fully documented in the schema ('SQL query to audit'), so the baseline is 3. The description adds the 'LLM-generated' provenance context but no format, dialect, or size constraints beyond what the schema already provides.

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 precise verb (statically validates), resource (LLM-generated SQL queries), mechanism (AST inspection), and the specific threat classes it targets (SQLi tautologies, UNION leaks, DROP/TRUNCATE). This distinguishes it from guardrail-style siblings like guardrail_verify or tool_output_firewall without opening any 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?

'LLM-generated SQL queries' and 'statically' imply the use case: pre-execution auditing of generated SQL. However, there is no explicit when-to-use/when-not guidance, no prerequisites, and no named alternative among the sibling guardrail tools, leaving the trigger condition to inference.

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

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

With no annotations, the description carries the full burden and does add concrete behavior: it strips invisible Unicode tags, markdown exfiltration beacons, and indirect prompt injections. However, it does not clarify whether it returns sanitized text, blocks on detection, preserves the original, or has side effects, which matters for a security sanitizer.

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?

A single front-loaded sentence with no wasted words. The core action and the specific sanitization targets are both stated immediately.

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?

The description gives enough to understand the tool's purpose, but with no annotations, no output schema, and 0% schema description coverage, it should also explain parameter meaning and return/blocking behavior. It is adequate but leaves important operational details unspecified.

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 0%, so the description must compensate for both parameters. It vaguely implies the required input is a tool output, but never explains raw_tool_output or source_tool_name semantics.

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: sanitizes untrusted tool outputs. It also names the exact threat classes removed, which distinguishes it from sibling security tools like scrub_pii_firewall and sql_injection_ast_guard.

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 phrase 'untrusted tool outputs' implies when the tool is relevant, but it does not explicitly say when to use it instead of siblings like guardrail_verify or scrub_pii_firewall. No exclusions or routing guidance are provided.

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