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

MEV & Market-Abuse Compliance Screen

dcl_evaluate_mev

POST-ACTION MEV & Market-Abuse Compliance Screen ($0.03). Text-level screen (not a mempool/transaction analyzer) for front-running/sandwich-attack language, wash trading/layering/spoofing, KYC/AML red flags (mixers, structuring, obscuring fund origin), and pump-and-dump/rug-pull language. Any critical-severity finding, or two or more major-severity findings, returns NO_COMMIT; a single major-severity finding is also returned as NO_COMMIT but with a distinctly higher confidence (~0.55 vs ~0.05-0.2 for harder violations) so downstream callers can tell a soft single flag apart from a hard multi-finding block. Each finding includes an illustrative regulatory_reference tag (MiFID II, FCA, or an EU AI Act article).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	Identifier of the agent that produced the response.
`response`	Yes	The agent or LLM response text describing or proposing an on-chain/trading action, to screen for MEV and market-abuse language.

Output Schema

TableJSON Schema

Name	Required	Description
`tx_hash`	Yes	Hash of this record in the tamper-evident audit chain.
`verdict`	Yes	COMMIT if the response passed the MEV/compliance 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).
`chain_index`	Yes	Sequential index of this record in the audit chain.

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?

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

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

Conciseness5/5

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

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

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

Completeness5/5

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

For a two-parameter screen with an output schema, the description fully explains what gets screened, how findings are classified, and how downstream callers should interpret the NO_COMMIT results. No critical call-time information appears missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents both params. The description adds no extra parameter-level detail; it only reinforces that 'response' is the text to be screened. Baseline 3 is appropriate because the schema carries the burden.

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

Purpose5/5

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

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

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

Usage Guidelines4/5

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

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

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

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.