Narrative analysis of a single confirmed transaction. AGENT BEHAVIOR: when the user pastes a tx hash (or an Etherscan / Arbiscan / Polygonscan / Basescan / Optimistic-Etherscan / Tronscan / Solscan URL containing one) and asks 'why did this fail / what does this do / what happened', call THIS too...
AI agents use explain_tx to create or update resources in VaultPilot MCP — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your VaultPilot MCP environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
hash | string | Yes | Transaction identifier. EVM: 32-byte hex (with or without `0x`). TRON: 32-byte bare hex. Solana: 64-byte signature as base58 (86–88 chars). |
chain | string | Yes | Which chain the tx lives on. Required because EVM / TRON / Solana post-mortems use different RPC paths and payload shapes. |
format | string | — | "structured" returns the JSON envelope only. "narrative" returns only the pre-rendered string. "both" (default) returns both — agents typically use the narrativ |
wallet | object | — | Optional. When supplied, balance + approval changes are computed FROM THIS WALLET'S PERSPECTIVE — outflows are negative, inflows positive. When omitted, default |
Parameters from the server's own tool schema.
An AI agent can call explain_tx faster than any human can review — one bad instruction and it creates or modifies resources in VaultPilot MCP by the hundred, each call as confident as the last.
Attacks that exploit this kind of access
Narrative analysis of a single confirmed transaction. AGENT BEHAVIOR: when the user pastes a tx hash (or an Etherscan / Arbiscan / Polygonscan / Basescan / Optimistic-Etherscan / Tronscan / Solscan URL containing one) and asks 'why did this fail / what does this do / what happened', call THIS tool — do NOT WebFetch the explorer or a Tenderly/Phalcon dashboard URL. Those pages are JS SPAs that render an empty shell when fetched server-side; this tool decodes the same data structurally and returns a verbatim-relayable narrative. Walks what actually happened: top-level method/instruction call, decoded ERC-20/TRC-20 Transfer + Approval events (or Solana SPL balance deltas), per-token balance changes for the wallet, fee paid, and a heuristics block flagging surprises (failed status, unlimited approval, dust outflow, transfer-to-zero burn, high-gas vs. moved value, unexpected no-state-change). Returns BOTH a structured envelope and a pre-rendered narrative string for verbatim relay (control via format). Distinct from get_transaction_status (just confirmation status) and the prepare→preview→send pipeline (forward-looking). Useful for debugging ("why did this swap return less than the quote?"), learning ("what does this contract call actually do?"), forensics ("what addresses did this tx touch?"), and address-poisoning triage. v1 covers EVM (Ethereum/Arbitrum/Polygon/Base/Optimism), TRON, and Solana — Bitcoin is deferred. v1 reads top-level execution only; internal calls / CPI / DeFi compositions surface via balance & event effects rather than as separate step rows. Pricing is current spot via DefiLlama (not historical at tx time). Optional wallet arg recomputes balance/approval changes from THAT wallet's perspective — defaults to tx sender. Read-only — no signing, no broadcast. It is categorised as a Write tool in the VaultPilot MCP MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
explain_tx accepts 4 parameters: hash, chain, format, wallet. Required: hash, chain. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for explain_tx: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
explain_tx is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the explain_tx rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for explain_tx. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
explain_tx is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.