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 the safety profile (readOnly, idempotent, non-destructive). The description adds some useful context: the tamper-evident nature of the chain and the monetary cost ($0.10). However, it doesn't elaborate on error behavior or specific guarantees, leaving room for more depth.

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, with two short sentences. It front-loads critical context (purpose and cost) and contains no wasteful filler. Every word 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?

This is a simple single-parameter tool with complete schema descriptions, comprehensive annotations, and an output schema. The description fully covers what the agent needs to know for selection and invocation; no additional information is necessary.

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 provides 100% coverage for the single required parameter 'tx_hash' with a clear description. The tool description merely repeats the parameter name and usage ('by tx_hash') without adding new meaning, matching the baseline for high schema coverage.

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 ('Retrieves') and resource ('record from the tamper-evident chain') with a clear method ('by tx_hash'), making the tool's function unambiguous. The 'Basic' distinction from the sibling 'dcl_audit_decode_deep' subtly differentiates the tool's scope.

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 purpose implies when to use the tool (retrieve an audit record by its hash), but there is no explicit guidance on when not to use it or when to prefer the 'deep' sibling variant. The prefix 'POST-ACTION' hints at context but doesn't provide a clear alternative or exclusion.

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 disclosing the extended output features (drift_context, full chain integrity verification) and the $0.50 cost, which are not in 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 a single, information-dense sentence that front-loads the key differentiators (deep, post-action, extended output, cost). Every element earns its place with no fluff.

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 low complexity (1 param), high schema coverage (100%), and presence of an output schema, the description is adequately complete. It mentions specific output extensions that matter for the tool's purpose, though it could clarify what 'drift_context' refers to.

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% for the single tx_hash parameter, so the schema fully documents it. The description does not add parameter-specific semantics, but with full coverage, 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 clearly indicates a read-only forensic audit operation, with 'Deep Forensic Audit' and 'Extended output with drift_context and full chain integrity verification' distinguishing it from the sibling dcl_audit_decode. It lacks an explicit verb like 'retrieve' or 'decode', but the intent is clear and differentiated.

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 implies usage via 'POST-ACTION' and 'Deep' versus the sibling dcl_audit_decode, suggesting the deep variant is for more thorough audits. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusions.

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?

Despite annotations already indicating non-read-only and non-idempotent behavior, the description adds meaningful context: the call 'always succeeds and simply seals the decision', the chain is append-only, and the receipt includes tx_hash, chain_hash, and chain_depth. These behavioral traits go beyond what annotations alone convey and are directly useful for an agent.

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 key phrase 'FINAL-STEP Leibniz Layer Crypto Commit ($0.01)' and every sentence earns its place: what it does, what it returns, how it differs from siblings, and when to call it. It is detailed but not bloated, and remains focused on 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?

With an output schema present and 100% input schema coverage, the description still adds essential context: return fields, the always-succeeds guarantee, the downstream-linking purpose of prior_checks, and job sequencing. This makes the tool fully understandable in context, even though the tool itself is relatively simple.

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 adds value beyond the schema by explaining the purpose of prior_checks ('records which earlier pipeline steps this specific commit is downstream of') and clarifying that it is optional but recommended. It does not add much detail for agent_id or decision, but the schema already covers them 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 states a specific verb+resource: 'Writes a trading/agent decision to the append-only Leibniz Layer audit chain and returns a Merkle-proof-style receipt.' It explicitly distinguishes itself from sibling tools by noting 'Unlike the evaluate_* tools, this call has no pass/fail verdict of its own.' This makes both the function and its unique role clear.

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 provides explicit when-to-use guidance: 'Always run this LAST, after every other crypto-suite check has passed.' It also clarifies exclusions by comparing against evaluate_* tools and noting that prior_checks is optional but recommended. This gives clear direction on sequencing and placement in a larger workflow.

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 provide minimal safety hints, but the description adds significant behavioral context: per-item pricing, independent verdicts, same logic as matching single-item tools, input-order results, shared batch_id, and rejection of oversized batches. 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 well-structured, front-loaded with the cost indicator, then logically covering input shape, policy defaults, behavior, output, limits, and usage guidance. Every sentence delivers essential information without fluff.

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?

Despite having an output schema, the description still clarifies return structure, ordering, pricing, policy options, and constraints. It is complete for a batch evaluation tool, covering cost, capacity, and relationships to sibling tools.

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?

While the schema describes both parameters, the description adds crucial semantics: the exact dict shape for each item, the default 'default' policy, accepted policy names, and the 200-item cap. This goes well beyond the schema's basic type descriptions.

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 the tool evaluates a list of items in one call and returns COMMIT/NO_COMMIT verdicts, distinguishing it from sibling single-item evaluate_* tools. It specifies the input shape, output ordering, and the batch behavior 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?

Explicitly instructs to use this instead of multiple single-item evaluate_* calls when checking several responses, optionally against different policies, for cost efficiency. Also mentions the 200-item cap, providing a concrete boundary.

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 significant behavioral details beyond annotations: the exact cost ($0.01), the policy algorithm (substring check with 0.7 confidence threshold), the confidence penalty (0.4 per forbidden match), the verdict criteria (NO_COMMIT if confidence below 0.7 or any match found), and that `reason` lists the triggering phrase. This adds rich context over the sparse annotations (all false hints) and contains no contradictions.

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?

Although the description is several sentences, every sentence is information-dense and earns its place. It is front-loaded with cost, then policy details, verdict logic, and usage guidance. There is no fluff or repetition; the structure flows logically from mechanism to decision criteria to when to use alternatives.

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 algorithmic complexity, the description covers all essential context: cost, threshold, forbidden phrases, confidence penalty, verdict outcomes, reason output, and usage compared to siblings. An output schema exists for return values, so not describing return shape is acceptable. The description is fully self-sufficient for an agent to select and invoke the 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% with both `response` and `agent_id` already described in the input schema. The tool description does not add further parameter-specific semantics; it focuses on policy and behavior. Baseline 3 is appropriate because the schema carries the parameter meaning fully, and the description doesn't introduce any additional parameter context.

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+resource: 'Runs the response through the server's default policy' with a detailed mechanism (substring check against 3 forbidden phrases). It clearly distinguishes from siblings by naming dcl_evaluate_strict, dcl_evaluate_jailbreak, dcl_evaluate_safety, and dcl_evaluate_quality as alternatives, making the tool's unique role as a low-cost first-pass gate unmistakable.

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?

Explicit guidance is provided: 'Use this as the default low-cost first-pass gate before a risky agent action; switch to dcl_evaluate_strict for a broader, higher-bar check, or to dcl_evaluate_jailbreak / dcl_evaluate_safety / dcl_evaluate_quality for a narrower, single-topic check.' This gives clear when-to-use and alternatives, fully satisfying the dimension.

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?

Despite annotations containing only false hints (which provide no positive safety/reliability information), the description discloses the exact algorithm, cost ($0.02), forbidden phrases, confidence threshold, and the matching confidence penalty. It also explains the exact output semantics (COMMIT vs NO_COMMIT with a reason), giving full behavioral transparency.

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: it states the pre-action cost, the policy mechanism, the return logic, and usage guidance. It is front-loaded with the most critical fact (PRE-ACTION check and cost) and contains 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?

Given the large sibling family of evaluators, the description provides enough context to select this tool correctly by naming the alternative dcl_evaluate_strict. It includes cost, algorithm, threshold, and output behavior, and an output schema exists so return values are already structured. The description is complete for the tool's complexity.

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 the schema already provides clear descriptions for both parameters (agent_id and response). The tool description does not add additional parameter-level semantics, but the baseline of 3 is appropriate because the schema carries the full 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 clearly states the tool runs the anti_jailbreak policy and returns COMMIT/NO_COMMIT, which is a specific verb plus resource. It also distinguishes itself from dcl_evaluate_strict by framing itself as a targeted, cheaper check for prompt-injection/persona-hijack risk, differentiating it from sibling 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?

Explicit usage guidance is provided: use this for specific prompt-injection/persona-hijack concerns, and use dcl_evaluate_strict when broader safety/default-policy coverage is needed. This clearly states when to use the tool versus 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 are all false and provide little behavior info. The description compensates by disclosing cost ($0.02), the output contract on match (NO_COMMIT with 'reason' and 'findings' naming categories), and that it evaluates the raw input. It does not describe behavior on no-match, but the output schema likely covers that; still, there is room for more detail on non-match 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?

The description is dense but information-rich: it starts with purpose and cost, then enumerates patterns, and ends with usage ordering and output. Every sentence adds value, though the pattern list is somewhat lengthy; still structured and 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?

Given the moderate complexity and presence of an output schema, the description provides essential context: crypto-specific patterns, return behavior, and pipeline positioning. It is complete enough for an agent to know when and why to use it, with the output schema covering detailed return values.

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 both parameters (response, agent_id) are already described. The description adds no parameter-specific semantics beyond the schema, making the baseline 3 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 ('screen') and a clear resource ('crypto-specialized instruction-override/jailbreak/injection'), enumerating exact patterns (drain-wallet, unlimited-approval) to differentiate it from generic jailbreak detection. It also positions itself first in the DCL crypto pipeline, clearly distinguishing from sibling tools like dcl_evaluate_jailbreak and dcl_evaluate_trade.

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?

Explicitly instructs to 'run this FIRST in the DCL crypto pipeline, before wallet/trade/MEV checks', and explains why: it screens the input itself rather than a decision built on top. This gives clear when-to-use guidance and alternatives, though it doesn't explicitly exclude non-crypto contexts, the specificity implies it.

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 annotations are all false and provide no positive hints, so the description carries the full burden. It discloses the cost ($0.03), the exact threshold logic for NO_COMMIT (critical or 2+ major, single major with distinct confidence), confidence values (~0.55 vs ~0.05-0.2), and the inclusion of regulatory_reference tags. This is rich, decision-relevant behavioral context beyond what annotations or schema 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 is dense but every sentence adds value: pricing, scope, detection categories, threshold logic, confidence distinctions, and output tag details. It is well-structured and front-loaded with the essential purpose and price, and the length is appropriate 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?

With an output schema present, the description doesn't need to explain return values, but it nonetheless details key behavioral outcomes (NO_COMMIT conditions, confidence levels). It also covers execution context (post-action, text-level) and cost. The tool is small (2 params), and the description is sufficient 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% for both parameters (response and agent_id), with clear descriptions already in the schema. The tool description adds no additional per-parameter meaning that isn't already present, so the baseline of 3 applies.

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 ('screen') and resource ('MEV & Market-Abuse... language'), and clearly defines its scope as a text-level compliance screen, explicitly distinguishing it from a mempool/transaction analyzer. It names the detection categories (front-running, sandwich attacks, wash trading, etc.) and the decision logic, making it clearly differentiated from sibling 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 provides clear context: it is a post-action screen for text describing on-chain/trading actions, and it explicitly states what it is not (not a mempool/transaction analyzer). It doesn't name alternative sibling tools, but the exclusions and specific domain provide strong guidance on when to use it.

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 provide almost nothing (all false), so the description carries full burden. It discloses that matches are replaced with [REDACTED], returns a single sanitized_output, and includes a narrow safety net with explicit limitations ('not a general toxicity classifier'). This is rich behavioral context well beyond 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 long but information-dense, with a clear lead sentence and each subsequent sentence adding specific value (placement, consistency, limitation). Slightly verbose but not wasteful; could be trimmed slightly without losing key details.

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 complexity and the presence of an output schema, the description fully covers return value (sanitized_output), execution order, consistency with sibling tools, and its safety-net scope. The output schema obviates the need to detail return structure, and the description still provides deployment context.

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, agent_id) are clearly documented. The tool description adds no extra parameter semantics, but the baseline of 3 applies because the schema already covers meaning fully.

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 ('strips') and resource ('raw model response'), and enumerates exact categories (secrets, PII, crypto material, network details, unsafe shell/SQL/path-traversal). It clearly distinguishes itself from sibling tools by positioning as the final gate before dcl_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?

Explicitly instructs to run as the LAST gate, after input-side checks like dcl_evaluate_jailbreak_crypto and immediately before dcl_commit. Also directs the agent to use the sanitized output whenever verdict is NO_COMMIT, and mentions consistency with dcl_evaluate_secrets/dcl_evaluate_pii for alternative usage.

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 valuable behavioral context beyond the all-false annotations, including the $0.02 cost, the regex scan methodology, and the critical side effect that 'Any finding results in NO_COMMIT'. It does not detail what NO_COMMIT entails operationally, so it is not fully transparent.

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 deliver the cost, method, and outcome without any redundancy. The description is front-loaded with the tool's purpose and retains only high-signal 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?

The description covers purpose, method, cost, and outcome, and an output schema exists. However, the meaning of 'POST-ACTION' and the operational effects of NO_COMMIT are left ambiguous, which slightly affects completeness even though the core functionality is well explained.

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% for both parameters, so the schema already fully documents the inputs. The description's mention of '8 personal-data categories' is useful context but does not add information about the parameters themselves beyond what the schema provides for the 'response' parameter.

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 it is a 'PII Detection Scan' with a specific method (regex-based, Luhn checksum) and a clear outcome ('NO_COMMIT'). It distinguishes itself from sibling tools like dcl_evaluate_secrets by focusing on personal data categories rather than generic secrets.

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 implies usage as a post-action gate via 'POST-ACTION' and 'NO_COMMIT', but it does not explicitly say when to use it or when to prefer alternatives. No exclusions or contrasts with the many dcl_evaluate_* siblings are provided, leaving the guideline implicit.

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 cost ($0.03), the confidence threshold (0.85), the exact return behavior (NO_COMMIT on match or low confidence, with reason listing matched phrases), and provides example phrases. This goes well beyond the sparse annotations, which only have false hints and thus don't contradict the description.

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 yet information-dense, with four sentences that each add unique value: cost and action, policy specifics, return behavior, and usage example. It is well-structured, front-loading the tool's name and purpose, 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?

Despite the output schema not being shown, the description covers the critical return behavior (NO_COMMIT and reason) and clearly explains the tool's role among many evaluate_* siblings. Given the moderate complexity, the description is complete for an agent to decide when and how to use it.

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%, and both parameters ('response' and 'agent_id') already have clear descriptions in the schema. The tool description adds context about the overall purpose but doesn't enrich the meaning of the parameters themselves, 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 clearly states the tool's function: runs the 'content_quality' policy, flags 12 specific phrases, and returns NO_COMMIT with a reason. It also distinguishes itself from siblings by noting it targets overconfident/unsubstantiated claims, a different concern from jailbreak or safety phrasing.

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?

Explicitly says to use this tool for catching overconfident or unsubstantiated claims before publishing agent-written copy or reports, and contrasts it with jailbreak/safety tools. Also notes it has the highest confidence bar of any single-policy tool, guiding when to choose it over others.

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 cost ($0.01), the exact policy mechanics (forbidden phrases, required substring, confidence penalty), the minimum confidence threshold, and the NO_COMMIT result with a reason field. This goes well beyond the annotations, which only indicate non-readOnly, non-idempotent, non-destructive.

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 well-structured, front-loaded with the cost and tool purpose. Every sentence adds unique value—policy details, confidence threshold, return behavior, and alternative tools—without redundancy or 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?

Given the tool's moderate complexity (custom policy, scoring, return behavior), the description fully covers what an agent needs to select and invoke it correctly. It also references the output schema's NO_COMMIT behavior and provides sibling tool alternatives, making the context 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?

The input schema already provides 100% coverage with explicit descriptions for both parameters. The description adds context about how the response is evaluated but doesn't introduce new parameter-level semantics 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 clearly states the tool runs a specific 'safety' policy with concrete behavior: flags two forbidden disclaimers, requires the substring 'AI', and returns NO_COMMIT below confidence 0.75. It explicitly distinguishes itself from sibling tools like dcl_evaluate_fast and dcl_evaluate_strict.

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: 'Use this when you specifically need to confirm an AI-disclosure marker is present and the two disclaimer phrases are absent.' It also gives a clear exclusion: 'not as a general-purpose safety net' and names alternatives 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?

Annotations are all false, so the description carries the full burden. It adds meaningful behavioral context: cost ($0.02), methodology (regex-based), scope (8 categories), and the blocking outcome (NO_COMMIT). This goes beyond annotations, though it does not describe potential side effects like logging or audit trails.

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 sentences, front-loaded with the tool's purpose and cost, followed by a compact list of categories and the decisive outcome. Every word earns its place; no fluff or redundancy.

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 complexity (2 simple params, output schema exists) and annotations, the description covers the essential context: what it scans, how it scans, cost, and outcome. It lacks explicit guidance on alternatives or integration with dcl_commit, but the 'POST-ACTION' and 'NO_COMMIT' hints provide sufficient context for the intended use.

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 documents both parameters (response to scan, agent_id). The description does not add any parameter-specific details beyond what the schema provides. It implicitly references 'response' but does not enhance parameter understanding.

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 verb+resource: 'POST-ACTION Secret & Credential Leak Scan' with a concrete scope ('Regex-based scan across 8 categories' including specific credential types). It also defines the outcome ('Any finding results in NO_COMMIT'), which distinguishes 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 description provides clear usage context by labeling the tool as 'POST-ACTION', implying it runs after an action and before commit. It also states the consequence of findings ('NO_COMMIT'), which guides when to use it. However, it does not explicitly name alternatives or exclusion criteria compared to other dcl_evaluate_* 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 discloses that it's a heuristic (not ground truth), mentions possible false positives, explains the pattern-based approach, and details the verdict/confidence collapsing logic. This goes beyond the minimal annotations (all false) and gives the agent a clear behavioral model.

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 well-structured and front-loaded with the cost and title. Each sentence adds value, covering purpose, flags, limitations, alternative workflow, and verdict logic without unnecessary verbosity.

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 usage context, limitations, cost, alternatives, and the full verdict collapsing rule. With an output schema present, the lack of return-value details is acceptable. The tool's complexity is fully addressed.

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?

Both parameters are already described in the input schema (agent_id, response) with adequate descriptions. The tool description does not add additional parameter-level semantics, so a baseline score of 3 is appropriate given 100% schema coverage.

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 the tool as a 'Market Signal Fabrication Screen' and details the exact patterns it flags (guaranteed-price-prediction language, absolute-certainty claims, fabricated-price flag, invented-token flag). It also distinguishes from the local grounding workflow, making its purpose unambiguous.

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 this is a 'POST-ACTION' heuristic pre-check and directs users to the 'local grounding workflow' when a full claim-by-claim check against a price-feed snapshot is needed. It also references dcl_evaluate_mev for the verdict collapsing rule, providing clear usage context.

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 specific behavioral traits beyond annotations: the $0.05 cost, 0.85 confidence threshold vs. 0.7, each phrase match costing 0.4 confidence, and the NO_COMMIT verdict with reason listing all matches. This is rich context that annotations alone do not provide, and there is no contradiction with the annotation flags.

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 earns its place: cost, policy definition, threshold, verdict behavior, and usage guidance. It is front-loaded with a clear title and cost, and the structure flows logically from what → how → when.

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 complexity and the presence of an output schema (which explains return values), the description sufficiently covers all necessary context: policy scope, thresholds, verdict conditions, and sibling comparisons. It leaves no major gaps for an AI agent to select and invoke the 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% for both parameters (response and agent_id), so the baseline is 3. The description adds no additional parameter-level semantics beyond what the schema already provides, which is acceptable given the full schema coverage.

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 the tool 'Runs the response against a broader, higher-bar strict policy' with specific details about thresholds and phrase matching. It distinguishes itself from siblings like dcl_evaluate_fast by explicitly naming that alternative and explaining the stricter policy coverage, making the tool's unique role unmistakable.

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 guidance: 'Use this instead of dcl_evaluate_fast when the cost of a false COMMIT is high — e.g. before an irreversible or high-stakes agent action.' This names the alternative and gives concrete use cases, making it clear when to choose this tool over others.

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 provide no useful hints (all false), so the description carries the full burden. It discloses the decision logic (unsafe patterns trigger NO_COMMIT, absence of 'risk' also triggers NO_COMMIT), the explicit output receipt structure (tx_hash/chain_hash/chain_depth), and the cost ($0.02). It also implies a write operation via the immutable receipt, going well beyond the 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 and packs a lot of detail into 3 sentences, including cost, screening criteria, the 'risk' requirement, and receipt structure. While it is longer than strictly necessary, the information is well-organized and every sentence contributes value, making it effective for a complex tool.

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 complexity, the description covers key aspects needed for selection and invocation: trigger conditions, output receipt, and purpose. It does not detail error cases or edge cases, but the presence of an output schema reduces the need to explain return values, making it sufficiently complete for an agent to use 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% for both parameters ('response' and 'agent_id'), so the schema already explains them. The description adds minimal over the schema, merely referring to 'trade-decision language' and 'the text,' which reinforces but does not expand on the meaning. Baseline 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 clearly states the tool's purpose: it screens trade-decision language for specific unsafe patterns and produces a commit/no-commit decision. It uses specific verbs ('screens', 'produces') and identifies the resource ('trade-decision language'), and the detail about the trade receipt 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 provides clear context for when to use this tool: it is a 'PRE-ACTION' verifier and explicitly states it is for 'downstream systems that specifically need a trade-shaped receipt object.' However, it does not name any alternative tools or explicitly state when not to use it, so it falls short of a perfect 5.

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 all-false annotations, it discloses concrete detection targets, the NO_COMMIT outcome, redaction behavior, and the guarantee that 'the real value is never returned or stored server-side.' It also specifies that sanitized_output is null if nothing is found, providing full behavioral transparency.

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 two sentences, starts with the title and cost, and packs dense details without fluff. The second sentence is long but well-organized, covering detection scope, fail action, output shape, and privacy—each 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?

It fully covers when to use the tool, what to expect, how output is structured, and why strictness matters, all while complementing the output schema. No critical context is missing for an agent deciding whether and how to invoke it.

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?

Although schema coverage is 100%, the description enriches the response parameter by detailing exact formats (e.g., 12 or 24 consecutive wordlist words, raw hex or WIF, Ethereum/Bitcoin addresses) that go beyond the schema's generic phrasing. This adds practical guidance for the agent.

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 ('Scans for') and defines the resource precisely: BIP-39 seed phrases, private keys, wallet addresses, and API keys in wallet context. It differentiates from siblings by emphasizing 'wallet secrets have no safe threshold, unlike other DCL evaluators,' making its role distinct.

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 frames the tool as a 'POST-ACTION' guard that triggers NO_COMMIT on any finding, implying it runs before committing. It contrasts with other DCL evaluators by noting the strictness, though it does not explicitly name alternative tools or when not to use them.

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 provides substantial behavioral detail beyond the annotations: the call does not link the pipeline_id to later evaluate_* calls, has no server-side session state, and is simply an 'identifier/timestamp issuer.' This directly informs the agent of the tool's true behavior, which the neutral annotations (all false) would otherwise leave ambiguous. It also discloses pricing, which is useful context.

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 brief but information-dense. The first sentence states the core purpose and result, the second provides the essential caveat and usage guidance, and the cost note is front-loaded. Every sentence earns its place, and the structure is logical: function → limitation → recommended 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?

For a simple parameter set (3 params, 1 required) and an output schema, the description completely covers the tool's behavior, limitations, and intended usage. It addresses the potential misconception that it creates a persistent server-side session, which is the most important missing context. No additional information is needed for an agent to 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?

The input schema already provides complete descriptions for all three parameters (scope, agent_id, ttl_seconds) with 100% coverage. The description adds a slight semantic link by mentioning that scope and expiry appear in the returned metadata, but it does not deepen the understanding of parameter formatting, constraints, or behaviors beyond what the schema states. Thus 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 action: 'Generates a new pipeline_id and returns session metadata.' This clearly distinguishes it from sibling evaluate_* and audit tools by identifying it as an identifier/timestamp issuer rather than a tracking session. The title 'Start Pipeline Session' is expanded with a precise functional definition, avoiding tautology.

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 tells when to use the tool: 'Use this to obtain a shared reference ID for your own client-side grouping of a multi-step audit sequence.' It also provides a critical exclusion: 'do not rely on it to automatically aggregate drift across calls.' This gives clear guidance on appropriate vs. inappropriate usage, going beyond a simple purpose statement.

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