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

Wallet Secret Guardian

dcl_evaluate_wallet

POST-ACTION Wallet Secret Guardian ($0.02). Scans for BIP-39 seed phrases (12 or 24 consecutive wordlist words), raw hex or WIF-format private keys, Ethereum/Bitcoin wallet addresses, and API keys/bearer tokens appearing near wallet/custody/signing terminology. Any finding results in NO_COMMIT — wallet secrets have no safe threshold, unlike other DCL evaluators. Returns a sanitized_output with all matches redacted (null if nothing was found) and a masked redacted_sample per finding — the real value is never returned or stored server-side.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	Identifier of the agent that produced the response.
`response`	Yes	The text to scan for seed phrases, private keys, wallet addresses, and wallet-context API credentials.

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	Yes	Human-readable explanation of the verdict.
`tx_hash`	Yes	Hash of this record in the tamper-evident audit chain.
`verdict`	Yes	COMMIT if nothing was found, otherwise NO_COMMIT. Wallet secrets have no safe threshold.
`findings`	Yes	All matches found. 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 scanned text (raw content is never stored).
`risk_score`	Yes	0.0-1.0 risk score based on number and severity of findings.
`chain_index`	Yes	Sequential index of this record in the audit chain.
`policy_version`	Yes	Version of the wallet-guardian policy that was applied.
`sanitized_output`	No	Input text with all matches redacted. Null if verdict is COMMIT.

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 goes well beyond annotations by explaining that findings result in NO_COMMIT, the real value is never returned or stored server-side, matches are redacted, and the output contains sanitized_output and masked redacted_sample. This provides strong behavioral transparency for a sensitive security scanner.

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 information-dense but every sentence adds value: it states cost, input scope, decision behavior, output structure, and security guarantees. There is no padding or repetition, and the most critical behavioral fact (NO_COMMIT) is front-loaded.

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?

The description is complete for a sensitive evaluation tool. It explains what gets scanned, what happens on findings (NO_COMMIT), what is returned (sanitized_output and redacted_sample), and the security invariant (real value never returned or stored). With an output schema present and only two parameters, nothing essential is 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%, and both parameters (response and agent_id) are adequately described in the schema. The description reinforces what response should contain but adds little parameter-level detail beyond the schema, 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.

Purpose5/5

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

The description states a specific verb ('Scans for') and a precise resource: BIP-39 seed phrases, raw hex/WIF private keys, Ethereum/Bitcoin addresses, and API keys/bearer tokens in wallet contexts. It clearly distinguishes itself from other evaluators by noting that wallet secrets have no safe threshold and any finding results in NO_COMMIT.

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 when to use this tool: for responses appearing near wallet/custody/signing terminology. It also contrasts it with other DCL evaluators, explaining that unlike them, wallet secrets have no safe threshold — making it clear this tool is the appropriate choice for wallet-secret detection where other evaluators' thresholds would be inadequate.

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.