get_transaction_history

Fetch a wallet's recent on-chain transaction history on a single chain, merged across external (user-initiated) txs, ERC-20/TRC-20 token transfers, and internal (contract-initiated) txs. Results are sorted newest-first, capped at limit (default 25, max 50), and annotated with decoded method names...

Server VaultPilot MCP vaultpilot-mcp
Category Read
Risk class Low
Parameters 81 required

What get_transaction_history does on VaultPilot MCP

AI agents call get_transaction_history to retrieve information from VaultPilot MCP without modifying anything — typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.

ParameterTypeRequiredDescription
chain string
limit integer
wallet object Yes
endTimestamp integer
startTimestamp integer
includeExternal boolean
includeInternal boolean
includeTokenTransfers boolean

Parameters from the server's own tool schema.

Why get_transaction_history needs a policy

Even though get_transaction_history only reads data, uncontrolled read access leaks sensitive information and racks up API costs — an agent caught in a retry loop can make thousands of calls a minute without anyone noticing.

Questions about get_transaction_history

What does the get_transaction_history tool do? +

Fetch a wallet's recent on-chain transaction history on a single chain, merged across external (user-initiated) txs, ERC-20/TRC-20 token transfers, and internal (contract-initiated) txs. Results are sorted newest-first, capped at limit (default 25, max 50), and annotated with decoded method names (via 4byte.directory) and historical USD values at the time of each tx (via DefiLlama). Supports Ethereum/Arbitrum/Polygon/Base/Optimism via Etherscan, TRON via TronGrid, and Solana via the configured Solana RPC. On Solana, results include a fourth item type program_interaction for DeFi calls (Jupiter swaps, Marinade/Jito liquid staking, Raydium/Orca swaps, native validator staking, or any unknown program) with balance-delta summaries showing net SOL + SPL changes for the wallet across the tx — more useful than raw instruction data for 'what happened to my wallet?'. includeInternal has no meaning for TRON (silently ignored) or Solana (doesn't have an 'internal' concept — CPI effects are captured inside program_interaction deltas). Use this to answer 'what did I do last week?', 'show me my recent swaps', or 'did I already approve X?' without the user pasting tx hashes. Read-only — no signing, no broadcast. Items may carry an optional suspectedPoisoning field flagging address-poisoning heuristics: zero_amount_transfer (USDC transferFrom 0-amount exploit, chain-agnostic), vanity_suffix_lookalike (dust tx whose counterparty mimics another counterparty's first-4 + last-4 hex chars; mimics field names the matched address), and self_suffix_lookalike (counterparty mimics the wallet itself). EVM-only for the suffix rules. AGENT BEHAVIOR: this field is for you, NOT for the user. Do NOT include flagged entries in the user-facing summary — they're noise that crowds out real activity (a single poisoned wallet can have dozens of dust-lookalike entries pinned at the top by recency). Filter them out silently; if the user asks 'is that everything?' or you want to be transparent about the filter, mention briefly like 'hid N suspected-poisoning entries (use the raw response if you want to inspect them)'. Surface a flagged entry only when the user explicitly asks about a specific tx hash that happens to match, or about address-poisoning attempts on this wallet. The point of the flag is to keep poisoning data accessible to your reasoning (e.g. when validating a future prepare_* recipient against the wallet's history) WITHOUT polluting chat with scam noise. It is categorised as a Read tool in the VaultPilot MCP MCP Server, which means it retrieves data without modifying state.

What parameters does get_transaction_history accept? +

get_transaction_history accepts 8 parameters: chain, limit, wallet, endTimestamp, startTimestamp, includeExternal, includeInternal, includeTokenTransfers. Required: wallet. The full parameter table on this page comes from the server's own tool schema.

How do I enforce a policy on get_transaction_history? +

Register the VaultPilot MCP server in PolicyLayer and add a rule for get_transaction_history: 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.

What risk level is get_transaction_history? +

get_transaction_history is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Can I rate-limit get_transaction_history? +

Yes. Add a rate_limit block to the get_transaction_history 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.

How do I block get_transaction_history completely? +

Set action: deny in the PolicyLayer policy for get_transaction_history. 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.

What MCP server provides get_transaction_history? +

get_transaction_history 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.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.