DCL Trust Oracle — AI/LLM Output Audit (x402 MCP)

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond the annotations by noting the $0.10 cost and the 'tamper-evident chain,' which conveys integrity and append-only behavior. This is meaningful supplemental information for an agent deciding whether to invoke the 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?

The description is extremely concise: two short clauses with no wasted words. The cost and action type are front-loaded, followed immediately by the core operation and lookup key. Every part 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 simple single-parameter retrieval with a rich output schema and safety annotations, the description is largely complete. The missing sibling differentiation and explicit usage context keep it from a 5, but an agent can correctly invoke the tool with the information provided.

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 the baseline is 3. The description's mention of 'by tx_hash' and 'retrieves a record' adds no meaning beyond the schema, which already describes tx_hash as the 'Transaction hash of the audit chain record to retrieve.'

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 clear verb and resource: it 'Retrieves a record from the tamper-evident chain by tx_hash.' This is specific and actionable. However, it does not explicitly distinguish itself from the sibling tool dcl_audit_decode_deep, relying only on the word 'Basic' in the title for differentiation.

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 explicit guidance on when to use this tool versus alternatives like dcl_audit_decode_deep. The 'POST-ACTION' and 'Basic' labels provide only a weak implied context, with no when-to-use or when-not-to-use direction, and no sibling is named.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by noting the $0.50 cost, the extended output fields (drift_context), and chain integrity verification, which are behavioral details not in the annotations. However, it does not disclose any additional operational constraints or response characteristics beyond these mentions.

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?

The description is concise (two sentences) and directly conveys the key differentiator ('extended output') and cost. It is not front-loaded with the most critical action verb, but it is efficient and free of fluff. The placement of 'POST-ACTION' first is somewhat ambiguous but not verbose.

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 an output schema present, the description need not explain return values, and annotations cover safety. The description provides enough to understand it's a deeper audit decode, but it lacks explicit guidance on when to choose it over dcl_audit_decode, and it does not clarify what 'POST-ACTION' means operationally. This leaves some gaps for an agent to make a fully informed decision.

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 the single parameter tx_hash is fully documented in the schema. The description adds no parameter-specific semantics; it only mentions output features. Baseline of 3 is appropriate since the schema already carries the burden.

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 labels the tool as 'Deep Forensic Audit' and mentions 'Extended output with drift_context and full chain integrity verification,' which implies it decodes an audit record in greater detail, but it does not explicitly state the action (e.g., 'retrieve' or 'decode') or the resource (tx_hash). It distinguishes from the sibling dcl_audit_decode only by the word 'Deep' and 'Extended output,' which is suggestive but not definitive.

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 says 'POST-ACTION' which hints at a usage context but does not explain when to use this deep variant versus the basic dcl_audit_decode or other audit tools. There is no explicit when-to-use, when-not-to-use, or alternative guidance, leaving the agent to infer that 'deep' means more detailed without clear criteria.

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?

The description adds meaningful behavioral detail beyond the annotations: the write goes to an append-only chain, the call always succeeds, it has no verdict of its own, and it returns a Merkle-proof-style receipt. The $0.01 cost is also disclosed up front. This gives the agent an accurate model of side effects and guarantees.

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?

The description is information-dense and every sentence contributes operational meaning. There is minor redundancy between 'FINAL-STEP' and 'Always run this LAST', but the repetition reinforces the most critical usage constraint. Overall it is well organized and front-loaded with the most important context.

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 output schema exists, the description covers everything else needed for correct invocation: when to call it, how it differs from siblings, what the receipt contains, and how prior_checks should be populated. No critical operational detail is missing for an agent deciding whether and how to call this 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 schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds extra value by explaining prior_checks as a record of downstream pipeline hashes, emphasizing that it is optional but recommended, and framing decision as the final trading/agent decision text. Only agent_id is left entirely to the schema, which 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?

The description names a specific action — committing a decision to the append-only audit chain — and clearly distinguishes itself from the evaluate_* sibling tools. It also spells out the concrete receipt fields (tx_hash, chain_hash, chain_depth), so an agent can immediately recognize this as the final sealing step rather than an evaluation.

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 explicitly states 'Always run this LAST, after every other crypto-suite check has passed', giving unambiguous pipeline ordering. It also contrasts this tool with evaluate_* tools by noting it has no pass/fail verdict, and it explains that prior_checks is optional but recommended for linking earlier pipeline steps.

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?

Annotations only assert false hints, so the description carries the transparency burden and delivers: it discloses per-item independent COMMIT/NO_COMMIT verdicts, input-order result mapping, a shared batch_id, a 200-item cap with rejection behavior, and a $0.10 price. It also explains that each item follows the same logic as the corresponding single-item evaluate_* tool, which is useful behavioral context beyond the 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?

The description is front-loaded with the cost and bulk nature, then uses compact, purposeful clauses to cover item shape, policy options, verdict behavior, result order, output field names, cap, and usage compared to alternatives. Every sentence adds information; there is no filler or repetition of the title/schema verbatim.

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 moderate complexity, the description supplies everything an agent needs to call it correctly: when to use it, item schema, policy defaults/options, per-item result semantics, output naming, and batch size limit. With an output schema also present, the absence of more detailed return documentation is not a gap.

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 the baseline is 3, but the description adds meaningful detail: the exact expected dict shape, the policy default of 'default', the allowed policy names, and the 200-item limit. It does not add anything for agent_id beyond the schema's own description, but the extra semantics on items clearly exceeds the bare 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 states a specific action ('Evaluates a list of items in one call'), defines the item shape and verdict type, and explicitly distinguishes itself from the single-item evaluate_* tools by being the batch variant. It also names the output (`results` plus `batch_id`) and the 200-item cap, so an agent can identify its role among the many sibling evaluate tools.

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?

It provides an explicit usage rule: 'Use this instead of multiple single-item evaluate_* calls when checking several responses... in one priced call rather than paying per item separately.' The cap ('oversized batches are rejected') also states a hard limit, and the ability to mix policies clarifies when this batch tool is a better fit than policy-specific single-item siblings.

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 annotations providing no positive safety hints (all false), the description carries the full burden and fully delivers: it discloses the $0.01 cost, the exact forbidden phrases, the 0.4 confidence penalty per match, the 0.7 threshold, and the precise verdict/reason behavior. This is far more behavioral detail than annotations alone provide.

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?

The description front-loads the purpose and cost, then gives the decision algorithm, and ends with routing guidance. Every sentence carries essential operational information and none is filler, so the length is justified by the 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?

For a two-parameter tool with an output schema, the description covers the policy details, cost, verdict semantics, and when to prefer sibling tools. There is no obvious gap that would prevent an agent from selecting and invoking this tool 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 already documents both parameters (response and agent_id) at 100% coverage, so the description does not need to add parameter-level semantics. The description adds no new meaning beyond the schema for these two parameters, hence the baseline score.

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 opens with a precise verb and resource: it runs the response through the server's default policy, and specifies the output verdicts (COMMIT vs NO_COMMIT) and triggering conditions. It also differentiates itself from named siblings (dcl_evaluate_strict, dcl_evaluate_jailbreak, etc.), so an agent can reliably pick it among the many dcl_evaluate_* tools.

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?

It explicitly instructs to use this as the default low-cost first-pass gate before risky agent actions, and tells exactly when to switch to dcl_evaluate_strict or to the narrower single-topic evaluators. No other tool in the set is given such direct selection guidance.

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?

The description discloses the exact mechanism: substring check, the six forbidden phrases, the 0.8 confidence threshold, the 0.4 per-match cost, and the COMMIT/NO_COMMIT outcomes with a reason. This far exceeds what the annotations provide and leaves no ambiguity about behavior.

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?

Dense but every clause earns its place: cost, policy, threshold, phrases, outcomes, and routing to the sibling alternative are all present without fluff. The core action is front-loaded, so an agent immediately understands what the tool does.

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?

Covers decision criteria, alternative tool routing, return outcomes, and pricing. With an output schema present, nothing an agent needs in order to invoke this 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 description coverage is 100%, so the baseline is 3. The description adds algorithmic context but does not enrich the meaning of the two parameters beyond what their schema descriptions already state.

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 ('Runs the anti_jailbreak policy') and names the exact detection scope: a substring check against six forbidden phrases. It explicitly distinguishes itself from dcl_evaluate_strict, so an agent can tell the tools apart without opening either 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?

The description explicitly states when to use this tool ('when the concern is specifically prompt-injection / persona-hijack risk') and names the alternative for broader coverage (dcl_evaluate_strict). This is textbook usage guidance with both a condition and an alternative.

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?

Annotations already cover mutation/destructive intent, but the description adds valuable behavioral detail: on a match it returns NO_COMMIT with `reason` and `findings` naming the matched categories. It also discloses the cost point ($0.02) and the fact that it is a pre-action gate. No contradiction with annotations exists, though it does not explicitly state the non-match return path.

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?

The description is dense but each clause adds functional value: the pre-action positioning, the category/examples, the return behavior, and the pipeline ordering. It could be slightly tightened, but it avoids fluff and front-loads the most important identification ('Crypto Jailbreak & Injection Detection') and operational context.

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 complex classifier with an output schema, the description covers what patterns are detected, what a match returns, and how it fits into the pipeline. It could be more explicit about how this differs from the generic dcl_evaluate_jailbreak sibling, but it names the relevant adjacent checks and gives enough context for correct invocation.

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 the schema already explains both `response` and `agent_id`. The tool description adds no new parameter-level detail beyond restating that `response` is the input to screen. The baseline of 3 is appropriate; the description does not harm but also does not carry additional parameter 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?

The description clearly identifies this as a specialized crypto jailbreak/injection detection screen, with a specific verb ('Detect'/'screens') and explicit resource (input prompts in the crypto pipeline). It differentiates itself from generic jailbreak detection by naming crypto-specific injection categories and examples, so an agent can distinguish it from siblings like dcl_evaluate_jailbreak, dcl_evaluate_wallet, and dcl_evaluate_mev.

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 explicit placement: 'run this FIRST in the DCL crypto pipeline, before wallet/trade/MEV checks.' It also explains why, noting this tool 'screens the input itself rather than a decision built on top of it.' This is concrete, actionable guidance that tells the agent when to use it relative to sibling tools.

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?

The description goes well beyond the sparse all-false annotations: it discloses the exact decision thresholds (NO_COMMIT for any critical, or two+ major), the confidence asymmetry (~0.55 vs ~0.05-0.2), and the presence of regulatory_reference tags. It also clarifies the textual nature of the screen and its post-action role.

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?

The description packs purpose, exclusions, severity thresholds, confidence values, and regulatory tags into three dense sentences with no filler. The core purpose is front-loaded, and every clause contributes actionable information.

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-parameter screen with an output schema, the description fully explains what gets screened, how findings are classified, and how downstream callers should interpret the NO_COMMIT results. No critical call-time information appears 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 description coverage is 100%, so the schema already fully documents both params. The description adds no extra parameter-level detail; it only reinforces that 'response' is the text to be screened. Baseline 3 is appropriate because the schema carries the burden.

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 ('Screen'), a resource ('MEV & Market-Abuse Compliance'), and a concrete scope: text-level analysis of responses proposing on-chain/trading actions. It enumerates specific violation categories and explicitly distinguishes itself from a mempool/transaction analyzer, making it easy to tell apart from the many evaluate_* siblings.

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?

It clearly states when to use: post-action text screening for front-running, wash trading, KYC/AML red flags, and pump-and-dump/rug-pull language. It provides one exclusion (not a mempool/transaction analyzer), but does not explicitly name sibling tools or state when to prefer dcl_evaluate_trade or other compliance variants.

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?

Beyond the annotations, it discloses the transformation behavior: "every match replaced by [REDACTED]" and "Returns a single sanitized_output." It also adds consistency context by noting it re-uses the same detection tables as dcl_evaluate_secrets/dcl_evaluate_pii. No contradiction exists with the provided annotations.

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?

The description is dense yet scannable: it front-loads the gate role, then lists redaction categories, output behavior, pipeline position, and sibling-tool consistency in compact clauses. Every sentence contributes actionable information with 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?

The description covers what is redacted, how the output is shaped, where the tool sits in the pipeline, and how it relates to sibling tools. With an output schema already present, there is no missing material an agent needs to select and invoke this tool 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?

Schema description coverage is 100%, so the schema already fully documents both `response` and `agent_id`. The description reinforces that `response` means the raw model response and that the returned value should replace it, but adds no new parameter-level constraints or formatting details.

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 precise verb-resource pair: it "strips secrets/credentials, PII, crypto material..." from "a raw model response." It also lists specific categories and explicitly says it is "not a general toxicity classifier," which sharply distinguishes it from sibling evaluate tools.

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 explicit placement advice: "Run this as the LAST gate" and "after dcl_evaluate_jailbreak_crypto/other input-side checks have already run, and immediately before dcl_commit." It also tells the agent when to consume the result: "use that instead of the original whenever verdict is NO_COMMIT."

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 all annotations false, the description carries the transparency burden and does meaningful work: it discloses that the scan is regex-based, covers 8 categories, applies a Luhn checksum for card numbers, and reports NO_COMMIT on any finding. It does not describe the output shape, but an output schema exists and there is no annotation contradiction.

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 short sentences front-load the action, cost, mechanism, and the critical NO_COMMIT consequence. 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?

For a simple two-parameter scan with a complete input schema and an output schema, the description provides cost, method, category scope, and the effect of findings. It is slightly incomplete in not routing the agent away from adjacent evaluate tools, but no fundamental calling detail 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 because both parameters are already fully documented. The description adds processing context such as regex categories and Luhn validation, but it does not add new meaning about agent_id or the input format beyond what the schema 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?

The description clearly identifies an 8-category PII scan with regex methodology and a NO_COMMIT consequence, so the core purpose is obvious. It does not explicitly differentiate from closely related siblings like dcl_evaluate_secrets, but the PII focus and method make the tool's role specific.

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 'POST-ACTION' label and NO_COMMIT outcome imply it belongs after an action and before committing, which is useful contextual guidance. However, the description never states when to prefer this over alternatives or which sibling tools cover adjacent concerns such as secrets and safety.

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?

Annotations carry little behavioral weight here (all hints false), so the description carries the burden and does so thoroughly: it discloses the $0.03 cost, the 0.85 minimum-confidence threshold, the NO_COMMIT return condition, and the `reason` output field. This gives the agent concrete expectations beyond what the schema provides.

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?

The description is dense but efficient, packing the threshold, phrase set, examples, return behavior, cost, and intended use into a short paragraph. Every sentence contributes purposeful guidance with 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?

The tool is fully described in context: what it checks, when to use it, how it differs from siblings, what triggers NO_COMMIT, and what the reason field contains. The output schema exists and the description still sketches the key return behavior, so an agent can select and invoke it confidently.

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 the baseline is 3. The description does not add significant parameter-specific meaning beyond framing the response as generated content, but the schema already documents both parameters clearly.

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 clearly names the specific resource ('content_quality' policy) and the exact action: flagging 12 absolutist or unverifiable-claim phrases. It also differentiates this from jailbreak or safety phrasing, making it easy to distinguish from sibling evaluate tools.

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?

It explicitly says 'Use this to catch overconfident or unsubstantiated claims in generated content' and gives a concrete use case: before publishing agent-written copy or reports. It also draws a boundary by noting this is 'a different concern from jailbreak or safety phrasing.'

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?

The description discloses far more than the annotations: the $0.01 cost, confidence penalty of 0.2, minimum confidence threshold of 0.75, NO_COMMIT return behavior, and how the reason field is populated. Annotations are limited and do not conflict with this rich behavioral detail.

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?

The description is dense but every sentence earns its place: cost, policy details, scoring behavior, return behavior, and usage guidance. It is front-loaded with the tool name and price, and uses clear separators to organize policy versus usage.

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 output schema exists and the annotations are minimal, the description provides everything an agent needs to correctly invoke the tool: exact inputs, policy, thresholds, return behavior, reason field content, and routing to alternative tools. Nothing material is left to inference.

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 schema already fully documents response and agent_id. The description adds functional context about how the response text is evaluated, but it does not add new parameter-level meaning beyond what the schema states.

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: 'Baseline Safety Check' that runs the 'safety' policy. It precisely defines the forbidden disclaimers and the required 'AI' substring, and distinguishes this tool from siblings by stating it is not a general-purpose safety net.

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?

It explicitly tells the agent when to use this tool: when an AI-disclosure marker must be present and the two disclaimer phrases must be absent. It also gives the exclusions and alternatives, saying to use dcl_evaluate_fast or dcl_evaluate_strict for broader coverage.

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?

Beyond annotations, the description discloses the detection method ('regex-based'), the category scope, the cost, and the gate behavior ('Any finding results in NO_COMMIT'). It does not explain what happens on a clean scan or whether findings are severity-ranked, but the output schema and simple annotations reduce the severity of that omission.

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?

The description is compact and information-dense: two sentences convey timing, cost, method, target categories, and outcome. There is no filler, and the most important usage constraint is front-loaded with 'POST-ACTION'.

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 with only two string parameters, complete schema descriptions, and an output schema, the description covers purpose, timing, and behavioral outcome adequately. It could be more explicit about when to choose this tool over sibling evaluate tools and what a no-finding result returns, but those are minor gaps.

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 clear descriptions for both 'response' and 'agent_id'. The description confirms that the response is the text to scan and adds credential categories, but it does not need to provide further parameter-level semantics. Baseline 3 is appropriate because the schema already carries the semantic load.

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 clearly names a specific operation ('scan') and resource ('secrets and credentials'), and further specifies the scope with concrete categories such as API keys, cloud credentials, tokens/JWTs, and private keys. This differentiates it from sibling evaluate tools like dcl_evaluate_pii or dcl_evaluate_safety.

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 'POST-ACTION' prefix and 'Any finding results in NO_COMMIT' give useful pipeline context, indicating the tool runs after an action and gates the commit. However, there is no explicit guidance about when to prefer this tool over sibling secrets-related or other evaluate tools, so the agent must infer selection 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 useful annotation hints (readOnly/destructive/idempotent all false), the description carries the burden and discloses key traits: it runs 'on the output text alone (no source price feed)', is not ground truth, and has false positives for lesser-known tickers. It also explains the verdict/confidence collapsing rule. It doesn't mention side effects, but this is a screening tool and no modification is implied.

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?

Dense single paragraph is front-loaded with title and cost, and each clause adds information about inputs, limitations, alternatives, or decision logic. It is longer than strictly necessary and could be broken into bullets, but there is 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?

For a 2-parameter tool with an output schema, the description is operationally sufficient: it defines inputs, behavior, limitations, cost, alternative workflow, and output decision rules. Nothing required to select and call the tool 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 covers 100% of parameters, so baseline is 3. The description does not add parameter-level semantics beyond what the schema already states, though it reinforces that 'response' is the text being screened.

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+resource: it screens market signal text for fabrication. It details four concrete flags and explicitly contrasts itself with 'the local grounding workflow' and references 'dcl_evaluate_mev', so an agent can distinguish it from siblings.

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?

It explicitly states when to prefer the alternative: 'For a full claim-by-claim check against an actual price-feed snapshot, use the local grounding workflow instead of this live tool.' It also characterizes itself as a 'heuristic pre-check', implying the quick-screening use case.

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?

Annotations are all false, providing no behavioral cues, so the description carries the full burden. It discloses cost ($0.05), policy composition (union of three policies), threshold mechanics (0.85 vs 0.7), per-phrase confidence penalty (0.4), and exact verdict behavior (NO_COMMIT with reason listing all matches). There is no contradiction with annotations.

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?

The description is dense but every sentence earns its place: cost, policy scope, threshold, penalty, verdict behavior, and routing guidance. The most important differentiator (when to use it) is front-loaded and repeated in the final sentence, and no filler or redundant language appears.

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 fully equips an agent to call this tool correctly: it explains the strict policy, the confidence mechanics, the output verdict, and the reasoning in 'reason'. Since an output schema exists and the closest sibling is explicitly distinguished, there is no missing decision-critical information.

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 'response' and 'agent_id' documented in the input schema. The description does not add new parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 ('runs the response against') and resource ('broader, higher-bar strict policy'), then adds concrete mechanics: 8 forbidden phrases, 0.85 minimum-confidence threshold, and NO_COMMIT verdict. It clearly differentiates from sibling dcl_evaluate_fast by explicitly contrasting the stricter policy and threshold.

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 explicitly states when to use this tool: 'Use this instead of dcl_evaluate_fast when the cost of a false COMMIT is high' and gives a concrete example ('before an irreversible or high-stakes agent action'). It names the alternative and the condition, leaving no ambiguity.

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 minimal annotation coverage (all hints false), the description carries the behavioral burden and does so thoroughly. It discloses the full decision logic: any unsafe match yields NO_COMMIT, the 'risk' keyword is required for COMMIT, and its absence alone triggers NO_COMMIT with a reason. It also explains the distinct immutable trade_receipt output and its purpose.

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?

The description is dense but every sentence contributes: the first states purpose and cost, the second and third define the evaluation rules and output decision, and the fourth explains the receipt object. It is front-loaded and contains no filler or redundant restatement of the schema.

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 moderate complexity, the annotations provide little support, and an output schema exists to cover return-value structure, the description is complete. It explains what is screened, the exact conditions for NO_COMMIT and COMMIT, the role of the 'risk' marker, and why the trade_receipt exists. An agent has enough information 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?

Schema description coverage is 100%, so the baseline is 3; both response and agent_id are already described in the schema. The tool description adds useful context about what the response text is screened for, but it does not meaningfully extend parameter-level semantics 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 uses a specific verb ('screens') and resource ('trade-decision language'), then names the exact criteria it checks: guaranteed-return claims, zero-risk/'can't lose' framing, and unqualified 'buy/sell X now' directives. This clearly distinguishes it from the sibling dcl_evaluate_* tools, which are generic or focused on other content types.

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 establishes clear context: this is a PRE-ACTION verifier for trade decisions, and it specifies exactly what kind of text is appropriate ('trade decision or recommendation text'). It does not explicitly name alternatives or state when not to use it, but the scope is specific enough that an agent can infer the right use case.

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?

The description goes well beyond annotations by explaining that findings result in NO_COMMIT, the real value is never returned or stored server-side, matches are redacted, and the output contains sanitized_output and masked redacted_sample. This provides strong behavioral transparency for a sensitive security scanner.

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?

The description is information-dense but every sentence adds value: it states cost, input scope, decision behavior, output structure, and security guarantees. There is no padding or repetition, and the most critical behavioral fact (NO_COMMIT) is front-loaded.

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 is complete for a sensitive evaluation tool. It explains what gets scanned, what happens on findings (NO_COMMIT), what is returned (sanitized_output and redacted_sample), and the security invariant (real value never returned or stored). With an output schema present and only two parameters, nothing essential 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 description coverage is 100%, and both parameters (response and agent_id) are adequately described in the schema. The description reinforces what response should contain but adds little parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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 ('Scans for') and a precise resource: BIP-39 seed phrases, raw hex/WIF private keys, Ethereum/Bitcoin addresses, and API keys/bearer tokens in wallet contexts. It clearly distinguishes itself from other evaluators by noting that wallet secrets have no safe threshold and any finding results in NO_COMMIT.

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 explicitly states when to use this tool: for responses appearing near wallet/custody/signing terminology. It also contrasts it with other DCL evaluators, explaining that unlike them, wallet secrets have no safe threshold — making it clear this tool is the appropriate choice for wallet-secret detection where other evaluators' thresholds would be inadequate.

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?

The description adds crucial behavioral context beyond the annotations by disclosing that there is no server-side session state and that the pipeline_id is not connected to subsequent evaluate_* calls. It also mentions the cost and the returned metadata fields, giving the agent an accurate model of what the tool does and does not do.

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?

The description is front-loaded with the core action and uses a follow-up sentence for important caveats and usage guidance. It is a bit long and somewhat repetitive around the 'no session state' idea, but every sentence contributes value.

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 three-parameter tool with an output schema available, the description covers the generated ID, returned metadata, intended use, monetary cost, limitations, and non-linkage to later audit calls. Nothing required for correct invocation and expectation-setting 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?

The input schema fully documents all three parameters with descriptions and defaults, so the description does not need to explain them. The description adds little parameter-level detail beyond mentioning scope and expiry in the return metadata, placing it at the schema-covered baseline of 3.

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 clearly states a specific action and resource: 'Generates a new pipeline_id and returns session metadata.' It also differentiates this tool from the many evaluate_* siblings by explicitly positioning it as an identifier/timestamp issuer rather than an active tracking session.

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?

It provides explicit usage instructions: 'Use this to obtain a shared reference ID for your own client-side grouping of a multi-step audit sequence.' It also gives a clear exclusion: 'do not rely on it to automatically aggregate drift across calls,' and warns that later evaluate_* calls are not linked to this ID.

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