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

Leibniz Layer Crypto Commit

dcl_commit

FINAL-STEP Leibniz Layer Crypto Commit ($0.01). Writes a trading/agent decision to the append-only Leibniz Layer audit chain and returns a Merkle-proof-style receipt: tx_hash (proof of this specific commit), chain_hash (the previous commit's hash, linking this one into the chain), and chain_depth (this commit's position in the chain). Unlike the evaluate_* tools, this call has no pass/fail verdict of its own — it always succeeds and simply seals the decision. Passing prior_checks is optional but recommended: it records which earlier pipeline steps (firewall/wallet/trade/MEV) this specific commit is downstream of, in one auditable record. Always run this LAST, after every other crypto-suite check has passed.

Input Schema

TableJSON Schema

Name	Required	Description
`agent_id`	Yes	Identifier of the agent whose decision is being committed.
`decision`	Yes	The final trading/agent decision text to commit to the audit chain.
`prior_checks`	No	Optional dict of tx_hashes from earlier pipeline steps (e.g. {'prompt_firewall_tx_hash': ..., 'trade_verifier_tx_hash': ..., 'mev_compliance_tx_hash': ...}), linking this commit to the specific checks that passed before it.

Output Schema

TableJSON Schema

Name	Required	Description
`tx_hash`	Yes	Tamper-evident proof of this specific commit.
`timestamp`	Yes	Unix timestamp when this record was sealed.
`chain_hash`	Yes	Hash of the previous commit in the append-only chain that this one links to.
`input_hash`	Yes	Hash of the committed decision text (raw content is never stored).
`chain_depth`	Yes	This commit's position (index) in the 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.8/5.0

Behavior5/5

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

The description adds meaningful behavioral detail beyond the annotations: the write goes to an append-only chain, the call always succeeds, it has no verdict of its own, and it returns a Merkle-proof-style receipt. The $0.01 cost is also disclosed up front. This gives the agent an accurate model of side effects and guarantees.

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

Conciseness4/5

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

The description is information-dense and every sentence contributes operational meaning. There is minor redundancy between 'FINAL-STEP' and 'Always run this LAST', but the repetition reinforces the most critical usage constraint. Overall it is well organized and front-loaded with the most important context.

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, the description covers everything else needed for correct invocation: when to call it, how it differs from siblings, what the receipt contains, and how prior_checks should be populated. No critical operational detail is missing for an agent deciding whether and how to call this tool.

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

Parameters4/5

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

The schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds extra value by explaining prior_checks as a record of downstream pipeline hashes, emphasizing that it is optional but recommended, and framing decision as the final trading/agent decision text. Only agent_id is left entirely to the schema, which is sufficient.

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 action — committing a decision to the append-only audit chain — and clearly distinguishes itself from the evaluate_* sibling tools. It also spells out the concrete receipt fields (tx_hash, chain_hash, chain_depth), so an agent can immediately recognize this as the final sealing step rather than an evaluation.

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?

The description explicitly states 'Always run this LAST, after every other crypto-suite check has passed', giving unambiguous pipeline ordering. It also contrasts this tool with evaluate_* tools by noting it has no pass/fail verdict, and it explains that prior_checks is optional but recommended for linking earlier pipeline steps.

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.