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

Trade Decision Verifier

dcl_evaluate_trade

PRE-ACTION Trade Decision Verifier ($0.02). Screens trade-decision language for guaranteed-return claims, zero-risk/"can't lose" framing, and unqualified "buy/sell X now" directives — any match is NO_COMMIT. If no unsafe language is found, COMMIT additionally requires the word "risk" to appear anywhere in the text as a minimum disclosure marker; its absence alone triggers NO_COMMIT with reason noting the missing disclosure. Produces an immutable trade_receipt (tx_hash/chain_hash/chain_depth) distinct from the top-level audit hash, for downstream systems that specifically need a trade-shaped receipt object.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	Identifier of the agent that produced the response.
`response`	Yes	The trade decision or recommendation text to screen.

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	Yes	Human-readable explanation of the verdict.
`verdict`	Yes	COMMIT if the trade decision's language passed the screen, otherwise NO_COMMIT.
`findings`	Yes	All matched patterns. Empty list if verdict is COMMIT.
`timestamp`	Yes	Unix timestamp when this record was sealed.
`confidence`	Yes	Confidence score of the verdict, from 0.0 to 1.0.
`input_hash`	Yes	Hash of the screened text (raw content is never stored).
`trade_receipt`	Yes	Immutable receipt for this trade-verification record.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 6, 2026

removedInput schema / properties / payment_id

Removed value: -{
-  "default": "",
-  "description": "Optional payment identifier returned by a previous call when payment is required",
-  "title": "Payment Id",
-  "type": "string"
-}

First observedAug 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, the annotations provide little support, and an output schema exists to cover return-value structure, the description is complete. It explains what is screened, the exact conditions for NO_COMMIT and COMMIT, the role of the 'risk' marker, and why the trade_receipt exists. An agent has enough information to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3; both response and agent_id are already described in the schema. The tool description adds useful context about what the response text is screened for, but it does not meaningfully extend parameter-level semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('screens') and resource ('trade-decision language'), then names the exact criteria it checks: guaranteed-return claims, zero-risk/'can't lose' framing, and unqualified 'buy/sell X now' directives. This clearly distinguishes it from the sibling dcl_evaluate_* tools, which are generic or focused on other content types.

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

Usage Guidelines4/5

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

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

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

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

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.