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

Baseline Safety Check

dcl_evaluate_safety

PRE-ACTION Baseline Safety Check ($0.01). Runs the "safety" policy: flags 2 forbidden disclaimers ("I cannot be held responsible", "no guarantees") and additionally REQUIRES the substring "AI" to appear somewhere in the response — missing it costs 0.2 confidence even with no forbidden phrase present. Minimum confidence is 0.75. Returns NO_COMMIT if confidence drops below 0.75, with reason naming the forbidden phrase found or the missing required pattern. Use this when you specifically need to confirm an AI-disclosure marker is present and the two disclaimer phrases are absent — not as a general-purpose safety net; for broader coverage use dcl_evaluate_fast or dcl_evaluate_strict instead.

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 to check for safety violations.

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	Yes	Human-readable explanation of why the verdict was reached.
`tx_hash`	Yes	Hash of this record in the tamper-evident audit chain.
`verdict`	Yes	COMMIT if the response passed policy checks, otherwise NO_COMMIT.
`seal_text`	Yes	Human-readable Leibniz Layer verification seal.
`timestamp`	Yes	Unix timestamp when this record was sealed.
`confidence`	Yes	Confidence score of the verdict, from 0.0 to 1.0.
`drift_mode`	Yes	Current drift status: NORMAL, WARNING, ESCALATION, or BLOCK.
`input_hash`	Yes	Hash of the evaluated response (raw content is never stored).
`verify_url`	Yes	Public URL to independently verify this seal.
`chain_index`	Yes	Sequential index of this record in the audit chain.
`drift_score`	Yes	Z-score measuring deviation of the recent commit rate from baseline.
`policy_version`	Yes	Version of the policy that was applied.

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.7/5.0

Behavior5/5

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

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

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

Conciseness5/5

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

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

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

Completeness5/5

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

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

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

Parameters3/5

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

Schema coverage is 100%, so the schema already fully documents response and agent_id. The description adds functional context about how the response text is evaluated, but it does not add new parameter-level meaning beyond what the schema states.

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

Purpose5/5

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

The description names a specific verb and resource: 'Baseline Safety Check' that runs the 'safety' policy. It precisely defines the forbidden disclaimers and the required 'AI' substring, and distinguishes this tool from siblings by stating it is not a general-purpose safety net.

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

Usage Guidelines5/5

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

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

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

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.