Determine whether an exact action name is allowed by returning ALLOW or BLOCK based on the configured allowlist. Use it to gate actions without executing them.
Return ALLOW or BLOCK for an exact action name using the configured TRACEGUARD_ALLOWED_ACTIONS allowlist. This tool does not execute the action. Arguments are not checked against per-tool schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | Yes | ||
| target_tool | Yes |
Changes observed during successful MCP inspections.
v0.1.8Does 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: it names the exact output values (ALLOW/BLOCK), clarifies it is non-executing, and warns that arguments are not validated against per-tool schemas. It omits edge behavior such as what BLOCK means for an unlisted action or error handling, which keeps it below a 5.
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 tight sentences with the outcome (ALLOW/BLOCK) front-loaded, zero filler, and each sentence contributing a distinct constraint.
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 or annotations exist, but the description supplies the return values and the validation scope, which covers the core of what an agent needs. Missing details about non-matching or malformed action names keep it from being fully complete.
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%, so the description must compensate, and it does reasonably: 'exact action name' explains that target_tool must match an allowlist entry verbatim, and the explicit note that arguments are not schema-checked explains the purpose (or non-purpose) of the second parameter. It still does not give the action-name format or an example, leaving some inference.
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 verb and resource: it returns ALLOW or BLOCK for an exact action name against the TRACEGUARD_ALLOWED_ACTIONS allowlist. It is immediately clear what the tool does, though with no sibling tools there is nothing to differentiate it 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?
Usage is implied rather than stated: an agent must infer this is a pre-flight policy check to run before performing an action. The scope caveats ('does not execute the action', 'arguments are not checked') clarify boundaries but no explicit when-to-use or alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.