dcl-trust-oracle

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which cover the safety profile. The description adds a $0.10 cost and 'POST-ACTION' context, which are useful but do not provide deep behavioral detail beyond what annotations offer.

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 sentence that efficiently conveys cost, action, and target, with no redundant or filler content. It is well-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 presence of an output schema and comprehensive annotations, the description is largely adequate. However, it could briefly mention the dcl_audit_decode_deep alternative or the payment flow to improve completeness, so it earns a 4 rather than a 5.

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 tx_hash and payment_id fully documented. The description only adds that retrieval is 'by tx_hash', which adds minimal value beyond the schema, so the baseline score 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 clearly states the tool retrieves a record from the tamper-evident chain by tx_hash, giving a specific verb and resource. However, it does not explicitly distinguish this from the sibling dcl_audit_decode_deep, so it falls short of a 5.

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?

No explicit guidance is provided on when to use this tool versus alternatives. The 'Basic' label implies a simpler option compared to dcl_audit_decode_deep, but there is no direct comparison or exclusionary language, leaving the agent without clear selection 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: the $0.50 cost, 'POST-ACTION' timing, and specific output fields like drift_context and full chain integrity verification.

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—one sentence plus a parenthetical—yet packs in the cost, the deep nature, and key output features. Every word adds value with no 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?

For a read-only tool with strong annotations and an output schema, the description is sufficient. It conveys the premium cost, the forensic depth, and the additional output fields. Payment and hash details are left to the schema, which covers them adequately.

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 tx_hash and payment_id, with clear descriptions in the schema. The tool description adds no additional parameter-level detail, 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 identifies this as a 'Deep Forensic Audit' with 'Extended output with drift_context and full chain integrity verification,' which distinguishes it from the sibling tool dcl_audit_decode. However, it lacks an explicit verb like 'decode' or 'retrieve,' relying on the tool name to convey the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the 'Deep' qualifier and the extended output description, suggesting it should be used for more thorough forensic audits. There is no explicit when/when-not guidance or mention of the simpler alternative dcl_audit_decode.

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 indicate readOnly=false, so the write behavior aligns. The description adds critical context: the tool 'always succeeds', costs $0.01, writes to an 'append-only' chain (immutability), and returns a receipt with tx_hash, chain_hash, and chain_depth. This goes beyond the annotations and provides a clear safety profile.

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 'FINAL-STEP' cue and cost. It contains several sentences but each adds value, covering functionality, exceptions, optional parameters, and usage order. It is slightly long but not verbose or redundant.

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 (write operation, receipt output, optional linking, pricing, ordering), the description covers all essential aspects: what it does, return format, contrast with siblings, usage ordering, and optional param guidance. The output schema exists, so not explaining return fields is acceptable, but the description still provides helpful detail.

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 all 4 parameters with descriptions (100% coverage). The description adds extra meaning for prior_checks by explaining its purpose as linking earlier pipeline steps and providing an example dict. However, it doesn't add much beyond the schema for payment_id, which is already documented. Overall, it enhances understanding but not exhaustively.

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: 'Writes a trading/agent decision to the append-only Leibniz Layer audit chain and returns a Merkle-proof-style receipt.' It uses a specific verb and resource, and explicitly distinguishes itself from sibling evaluate_* tools by noting it has 'no pass/fail verdict of its own.'

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: 'Always run this LAST, after every other crypto-suite check has passed.' It also contrasts with evaluate_* tools, indicating when not to use them, and explains the optional but recommended use of prior_checks to record upstream 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 are all false, giving little safety or side-effect info. The description compensates by disclosing behavioral traits: independent COMMIT/NO_COMMIT per item, results returned in input order, a shared batch_id, no enforced size limit, and the fact that it is a 'PRE-ACTION' priced call. This goes well beyond the annotations and adds valuable execution 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 dense but each sentence contributes: purpose, item shape, policy behavior, result details, and usage guidance. It is front-loaded with the key fact (bulk evaluation) and avoids filler. It could be slightly trimmed, but 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?

Given the tool has an output schema (covering return values), the description appropriately omits return format details. It covers item structure, policy options, default behavior, ordering, batch_id, size limit, and when to use it. The description is sufficiently complete for an agent 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 coverage is 100%, so baseline is 3. The description adds meaningful detail beyond schema: it lists valid policy names, explains the default policy, and clarifies that each item is independently evaluated. It also notes there is no size limit on items, which is not in the schema. This adds real semantic value.

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: 'Evaluates a list of items in one call' with a precise item shape and policy semantics. It explicitly distinguishes from sibling tools by positioning itself as the batch alternative to single-item evaluate_* tools, and even names the sibling category ('matching single-item evaluate_* tool').

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 usage guidance: 'Use this instead of multiple single-item evaluate_* calls when checking several responses — optionally against different policies — in one priced call rather than paying per item separately.' This states when to use, the alternative, and the cost benefit, 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?

The description discloses critical behavioral traits beyond annotations: the exact algorithm (substring check), the three forbidden phrases, the minimum-confidence threshold (0.7), how matches affect confidence (0.4 penalty), and the verdict logic (NO_COMMIT if any match or confidence below threshold). It also reveals the cost ($0.01), which annotations do not provide. No contradiction with annotations exists.

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 appropriately sized for the tool's complexity, front-loaded with the tool name and cost. Every sentence carries meaningful information: policy mechanics, threshold, verdict, usage guidance, and alternative tools. No wasted words, and the structure logically flows from what it does to when to use it.

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 simple but has nuanced evaluation logic. The description explains the decision-making process, the constraints, and the alternatives. Since an output schema exists, return-value details are not needed. The combination of algorithm, threshold, verdict logic, and usage policy makes the description complete for correct selection and 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 baseline is 3. The description does not add explicit parameter-level semantics beyond what the schema already states, but it does provide contextual meaning for the 'response' parameter (the text to audit) implicitly. This is adequate but not exceptional.

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 with a specific verb and resource: it runs the response through the server's 'default' policy, performing a substring check against three forbidden phrases. It distinguishes itself from sibling tools by explicitly naming dcl_evaluate_strict and other alternatives, making the purpose 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?

The description provides explicit usage guidance: 'Use this as the default low-cost first-pass gate before a risky agent action' and then specifies when to switch to dcl_evaluate_strict or dcl_evaluate_jailbreak/safety/quality. This clearly covers when to use the tool versus alternatives.

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 all set to false, the description carries full burden for behavioral disclosure. It details the algorithm (substring check against 6 phrases), thresholds (0.8 confidence, 0.4 cost per match), return values (COMMIT/NO_COMMIT), and cost ($0.02), making the tool's behavior 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?

The description is three sentences long, front-loading the purpose and cost, then detailing the algorithm, then providing usage guidance. Every sentence adds value and there is 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?

The description explains the check's purpose, algorithm, thresholds, return values, cost, and when to use it versus alternatives. With an output schema present and a straightforward check tool, this is complete and sufficient for an agent 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. The description does not add any additional parameter-specific semantics beyond what the schema already provides; it only describes the overall policy, not the parameters themselves.

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 to check for forbidden phrases, with a specific verb ('runs') and resource ('response'). It distinguishes from sibling tools by naming the targeted use case and explicitly comparing with 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?

The final sentence explicitly states when to use this tool (targeted prompt-injection/persona-hijack risk) and when to use dcl_evaluate_strict instead (when safety/default-policy phrases are also needed). This provides clear, actionable guidance and names 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?

All annotations are false, so the description carries the full burden. It discloses the cost ($0.02), the return behavior on match ('NO_COMMIT with reason and findings'), and the PRE-ACTION nature of the check. This adds valuable behavioral context beyond the structured fields.

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-organized: it opens with the tool's role and cost, lists output behavior, then gives pipeline placement. Every sentence contributes specific information, and it is appropriately front-loaded with the most critical facts.

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 complexity of crypto-specific injection detection, the description covers the key categories with examples, states the return format, and provides explicit usage context. With an output schema present and sibling tools named, this is complete and self-sufficient for an agent.

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 all parameters, so the schema already explains 'response', 'agent_id', and 'payment_id' clearly. The description adds no parameter-level details, so a baseline score of 3 is appropriate, as it does not exceed the schema's explanatory power.

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?

Clearly states it is a 'Crypto Jailbreak & Injection Detection' screen, with specific examples of drain-wallet and unlimited-approval injections. Distinguishes from sibling dcl_evaluate_jailbreak by explicitly being 'Crypto-specialized' and focusing on crypto-specific patterns.

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 '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 of it. This is precise when-to-use guidance with a clear position relative to alternatives.

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 NO_COMMIT decision rule (critical severity or two+ major findings), confidence score differentiation (~0.55 vs 0.05-0.2), and the inclusion of regulatory_reference tags. This goes well beyond the annotations, which only set all hints to false, providing substantial useful behavioral 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 dense but each sentence adds value: cost, scope, violation categories, decision thresholds, and output metadata. It is well-structured with clear clauses, though the threshold logic could be simplified for readability.

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 thoroughly covers what the tool expects (response text), what it detects, how it decides (NO_COMMIT logic), and what output to expect (regulatory_reference). With an output schema present, this additional explanatory detail makes the description highly complete for a compliance screening 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 input schema already provides complete descriptions for all three parameters (100% coverage). The tool description adds no parameter-specific details beyond the schema; it focuses on behavior rather than enriching parameter semantics, so the 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 identifies the tool as a text-level compliance screen for MEV and market-abuse language, listing specific violation categories (front-running, wash trading, KYC/AML red flags, pump-and-dump) and explicitly distinguishing it from mempool/transaction analyzers. This makes it unique among the 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 states 'POST-ACTION' to indicate when the tool should be used, and notes it is not a mempool/transaction analyzer, which helps rule out some alternatives. However, it does not explicitly name sibling tools or provide direct comparison guidance for choosing this over other dcl_evaluate_* 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?

With annotations all false and providing no safety hints, the description carries full burden. It thoroughly discloses behavior: categories sanitized, replacement with '[REDACTED]', single return value, internal reuse of detection tables from dcl_evaluate_secrets/dcl_evaluate_pii, and pipeline placement. 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 front-loaded with the tool's role and cost, then systematically covers categories, replacement behavior, output, and pipeline positioning. Every sentence adds value, and the structure flows from what → how → when → consistency.

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 existence of an output schema, the description is fully complete. It covers all key aspects: input types, sanitization categories, output format, usage context, and relationship to sibling tools, without needing to explain return values in detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for all three parameters, so the baseline is 3. The description adds context about the $0.02 cost and pipeline order but does not explain parameter syntax beyond what the schema already provides. It correctly orients 'response' as the raw model output and 'sanitized_output' as the result, but the schema already conveys this.

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 'FINAL-GATE Output Sanitizer' and immediately states it 'strips secrets/credentials, PII, crypto material...' from a raw model response. It names specific resources and actions, and distinguishes itself from siblings by positioning itself as the last pre-commit gate.

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 as the LAST gate before a response reaches its destination — after dcl_evaluate_jailbreak_crypto/other input-side checks have already run, and immediately before dcl_commit seals the final decision.' Also clarifies when to use the output ('use that instead of the original whenever verdict is NO_COMMIT') and that it is not a general toxicity classifier.

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 beyond annotations by disclosing the cost ($0.02), the method (regex-based with Luhn checksum to reduce false positives), the scope (8 personal-data categories), and the critical behavioral outcome (NO_COMMIT if any finding). This gives the agent a clear picture of side effects and consequences, which is especially valuable given that annotations are sparse and readOnlyHint is false.

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 and front-loaded: it starts with the action and context ('POST-ACTION PII Detection Scan ($0.02)'), then explains the method and outcome in two more short sentences. Every sentence adds value, no waste 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?

For a scanning tool with an output schema present, the description does not need to explain return values. It explains when to use it (post-action), what it scans (8 categories), how it works (regex, Luhn), its cost, and its outcome (NO_COMMIT). This is sufficient for an agent to understand the tool's role and consequences.

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 thorough descriptions for all parameters (100% coverage), including the list of data categories in the 'response' field and the optional payment_id. The description adds context about the scan method and cost, but no additional parameter-level semantics, so it meets the baseline for good schema coverage without extra param clarity.

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: 'POST-ACTION PII Detection Scan' with regex-based scanning across 8 personal-data categories. It explicitly mentions the outcome 'Any finding results in NO_COMMIT', making the purpose specific. However, it does not differentiate itself from sibling tools like dcl_evaluate_secrets or dcl_evaluate_safety, so it relies on the name to distinguish.

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 a usage context by labeling the scan as 'POST-ACTION' and stating that any finding results in NO_COMMIT, implying it should be used as a gate after an action before committing. However, it does not explicitly state when to use this tool versus alternatives such as dcl_evaluate_secrets or dcl_evaluate_safety, nor does it mention exclusions or alternative scenarios.

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 minimal annotations (all false hints), the description discloses cost ($0.03), PRE-ACTION nature, return condition (NO_COMMIT with reason), threshold (0.85), and phrase count (12). This significantly enriches behavioral understanding without contradicting 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 compact and front-loaded with cost and purpose. Each sentence adds unique value: policy execution, thresholds, return behavior, and usage context. No redundant or filler 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?

With an output schema present and a rich description covering cost, threshold, trigger conditions, and use cases, the tool is fully understood. The contrast with sibling tools and examples complete the 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%, so the schema already documents parameters. The description adds no additional parameter detail, making the baseline score of 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 clearly states a specific verb+resource: 'Runs the content_quality policy' and flags 12 specific phrase types with a threshold. It distinguishes from siblings by noting it's 'a different concern from jailbreak or safety phrasing' and the 'highest bar of any single-policy tool'.

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 to catch overconfident or unsubstantiated claims in generated content' with an example ('before publishing agent-written copy or reports') and an explicit contrast to alternatives ('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 is highly transparent about behavioral details beyond the minimal annotations: it discloses the cost ($0.01), the exact policy rules (flagging two disclaimers, requiring 'AI'), the confidence penalty (0.2), the minimum threshold (0.75), and the return behavior (NO_COMMIT with reason). This goes well beyond the sparse annotations and fully informs the agent of side effects and outcomes.

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 most critical information (cost and policy). It consists of four sentences, each adding meaningful detail without redundancy. Slightly more compact than possible, but the density is justified by the richness of the behavior described.

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—custom policy, confidence threshold, multiple sibling alternatives—the description covers all essential aspects: cost, exact policy mechanics, threshold, return value semantics, and usage guidance. The presence of an output schema further reduces the need to describe return values, but the description still explains the NO_COMMIT outcome and reason field, making it highly 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 for all three parameters, with clear descriptions for agent_id, response, and payment_id. The tool description does not add additional parameter-level meaning beyond what the schema 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 clearly states the tool's function: it runs a specific 'safety' policy that flags two forbidden disclaimers and requires the substring 'AI'. It also distinguishes itself from siblings by naming alternatives for broader coverage, making the 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 when to use this tool ('when you specifically need to confirm an AI-disclosure marker is present and the two disclaimer phrases are absent') and when not to ('not as a general-purpose safety net'), with named alternatives (dcl_evaluate_fast or dcl_evaluate_strict). This provides clear usage 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 adds meaningful behavioral context beyond the sparse annotations (all false): it discloses the scan categories, the monetary cost ($0.02), and the critical fact that any finding results in NO_COMMIT. This is not present in the structured annotations and is essential for correct usage.

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 that pack the tool's purpose, scope, cost, and outcome. It is front-loaded with the tool name and provides zero wasted words.

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 params are well-documented, the description is sufficient for an agent to understand the tool's role and impact. It could more explicitly mention how results are returned (e.g., a flag or list), but the NO_COMMIT consequence and scope make it complete enough; a minor gap is not positioning against alternatives.

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 covers all three parameters with descriptions, achieving 100% coverage. The description adds no additional parameter-level detail, but schema descriptions already explain 'response' and 'agent_id' clearly, 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 performs a regex-based Secret & Credential Leak Scan across 8 specific categories (API keys, cloud credentials, tokens, etc.) and introduces a concrete outcome (NO_COMMIT). This specificity distinguishes it from sibling evaluator tools like PII or safety scans.

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 the NO_COMMIT consequence clearly indicate when to use the tool (after an action, likely before commit). However, it does not explicitly name alternative tools or exclusions, leaving some ambiguity among the many evaluate_* 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?

Beyond annotations, the description discloses cost, heuristic nature, false-positive risk, absence of price feed, specific flags, and verdict collapsing rule. Highly transparent about limitations and 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 well-structured and front-loaded with name, cost, and core purpose. Every sentence adds meaningful detail, and the use of dashes and lists aids readability without waste.

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 (multiple heuristic flags, confidence rules, alternatives), the description covers all essential context: what it checks, limitations, cost, workflow relationship, and verdict logic. Output schema exists, so return values are covered.

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 does not add much beyond the schema for 'response' and 'agent_id', but the schema descriptions are already clear. No need for extra elaboration.

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: it screens market signal text for fabrication patterns. It clearly distinguishes from the local grounding workflow and references shared logic with dcl_evaluate_mev, establishing sibling 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?

Explicitly positions the tool as a POST-ACTION heuristic pre-check and names an alternative ('For a full claim-by-claim check... use the local grounding workflow instead'). Provides clear context on when to use this vs. other 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 disclosure goes well beyond the annotations, which are all false and thus uninformative. It details the $0.05 cost, the union of 8 forbidden phrases, the 0.85 confidence threshold, the per-match confidence penalty, and the exact verdict logic (NO_COMMIT with reason listing matches). This is highly 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?

The description is concise yet information-dense, starting with a clear title and cost, then explaining the policy, thresholds, and usage context. Every sentence adds value without unnecessary 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?

The description covers purpose, usage, behavior, and outcomes (NO_COMMIT with reason). With an output schema present, return value details are not necessary. It provides sufficient context for an agent to decide when and how to invoke the 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides; it focuses on the tool's behavior rather than individual parameters.

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: it runs the response against a broader 'strict' policy and returns NO_COMMIT under certain conditions. It also distinguishes itself from dcl_evaluate_fast, making the purpose specific and 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?

Explicit guidance is provided: 'Use this instead of dcl_evaluate_fast when the cost of a false COMMIT is high', with concrete examples like irreversible or high-stakes actions. This clearly differentiates when to use this tool vs alternatives.

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 decision logic (match → NO_COMMIT; otherwise COMMIT requires the word 'risk'), costs ($0.02), and the creation of an immutable trade_receipt with specific fields. This goes well beyond the minimal annotations and clearly explains the tool's mutating behavior without contradicting 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 three sentences, each dense with necessary information: purpose/cost, decision rules, and output structure. It is front-loaded with the title and cost, and every sentence earns its place without fluff or repetition.

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 that an output schema exists and annotations are present, the description provides all necessary context: input language, decision thresholds, required disclosure marker, and the distinct receipt output. It fully covers the tool's behavior and intended integration point, making it complete for an AI agent to select and invoke 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 all parameters already have meaningful descriptions in the schema. The tool description does not add additional parameter-specific details beyond referring to 'trade-decision language' context, which aligns with the 'response' parameter but does not enhance understanding of agent_id or payment_id.

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 'Trade Decision Verifier' that 'screens trade-decision language' for specific unsafe patterns. It names concrete examples (guaranteed-return, zero-risk, unqualified buy/sell directives) and the output decision (NO_COMMIT/COMMIT), fully distinguishing it from sibling evaluation 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 indicates this is a 'PRE-ACTION' verifier and mentions it serves 'downstream systems that specifically need a trade-shaped receipt object,' giving clear context for appropriate use. However, it does not explicitly name alternative tools or state when NOT to use it, so some ambiguity remains.

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 all annotations being false, the description provides substantial behavioral detail: it scans for specific secret types, triggers NO_COMMIT, redacts findings, returns sanitized output and masked samples, states the real value is never returned or stored, and notes there is no safe threshold. This goes 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 compact and front-loaded with the tool's name and cost, followed by precise scanning criteria and outcome behavior. Every sentence conveys essential information without redundancy, making it appropriately concise 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?

Given the output schema, annotations, and parameter schema, the description fills all necessary gaps: it explains the NO_COMMIT behavior, redaction format, null handling, and server-side storage privacy. This is complete guidance for an agent selecting and invoking the 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?

Schema description coverage is 100%, so the baseline is 3. The description adds the wallet-specific scanning context (response is the text to scan), but it doesn't add detail about parameters beyond what the schema already states for each field.

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 ('scans for'), a clear resource (wallet secrets in responses), and the tool's role as a POST-ACTION evaluator. It distinguishes itself from sibling evaluators by focusing on wallet-specific secrets and explicitly noting it differs from other DCL evaluators.

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 when to use: post-action scanning for wallet secrets and any finding results in NO_COMMIT. It differentiates via 'unlike other DCL evaluators' but does not name specific alternative tools or explicitly state when not to use, so it falls short of a 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?

The description discloses crucial behavioral limitations beyond the annotations: there is no server-side session state linking to later evaluate_* calls, the tool is effectively an 'identifier/timestamp issuer', and it has a cost ($0.05). These details prevent the agent from mistakenly assuming the tool provides persistent session tracking. No annotation contradiction exists.

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 comprehensive, front-loaded with the primary purpose, followed by a clearly separated note about limitations. Every sentence adds value: the first sentence states the function, the second clarifies the non-persistence, and the third gives usage advice. No fluff or repetition.

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 relatively simple tool with 4 parameters (1 required) and a full output schema, the description is complete. It covers purpose, limitations, cost, and usage context. The presence of an output schema means return values need not be described in text, so nothing significant 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 already covers all parameters with descriptions (schema coverage 100%), so the description does not add much parameter-level semantics. It does mention 'scope' and 'expiry' in the output context, but doesn't explain any parameter beyond what the schema already provides. Baseline 3 is appropriate given 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's function: 'Generates a new `pipeline_id` and returns session metadata (scope, expiry, initial drift_mode)'. This is a specific verb+resource combination. It also distinguishes itself from the sibling evaluate_* tools by clarifying it is a session/pipeline starter, not an audit execution tool.

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 says when to use it: 'Use this to obtain a shared reference ID for your own client-side grouping of a multi-step audit sequence'. It also tells the agent what not to expect: 'do not rely on it to automatically aggregate drift across calls'. This provides clear guidance and sets boundaries relative to alternatives.

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