Examples

These walkthroughs show how Claude uses Tenderly MCP tools to complete real development tasks. You don’t need to call tools by name — just describe what you want and Claude handles the rest.

Create a Virtual TestNet and fund a wallet

What to ask:

“Create a Virtual TestNet forked from Ethereum mainnet and fund my wallet 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 with 100 ETH.”

What Claude does:

1. Calls list_projects to find your projects, then set_active_project to select one.
2. Calls get_networks to find the Ethereum mainnet network ID.
3. Calls create_vnet with the network ID, creating a forked environment.
4. Calls fund_account with the VNet ID and your wallet address, setting the balance to 100 ETH in hex wei.
5. Returns the VNet details including Admin RPC and Public RPC URLs, ready for use in Hardhat, Foundry, or any Web3 library.

What you get back:

A running Virtual TestNet forked from latest mainnet state, your wallet funded, and RPC URLs you can drop into your development framework config.

Simulate a Uniswap swap

What to ask:

“Simulate a swap of 1 ETH for USDC on Uniswap V3 from 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 on Ethereum mainnet. Show me the expected output and any token transfers.”

What Claude does:

1. Calls simulate_transaction with the Uniswap V3 router address, your sender address, the swap calldata, and 1 ETH as value.
2. The simulation runs against current mainnet state and returns: success/revert status, gas used, and decoded method name.
3. Calls get_simulation_asset_transfers to show all token movements — the ETH going in and USDC coming out.
4. Calls get_simulation_balance_changes to show the net impact on your balances with USD values.

What you get back:

The exact USDC output, gas cost, and a breakdown of every asset transfer. If the swap would revert (e.g., slippage too high), you get the decoded revert reason.

Pre-flight check a transaction before sending

What to ask:

“I’m about to call approve on 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 to give 0xE592427A0AEce92De3Edee1F18E0157C05861564 unlimited USDC allowance. Simulate it first and show me exactly what approvals and state changes it will create.”

What Claude does:

1. Calls simulate_transaction with your wallet as sender, the token contract as recipient, and the approve calldata.
2. Calls get_simulation_exposure_changes to show every approval and allowance change — which spender gets access to what, and how much.
3. Calls get_simulation_state_changes to show the exact storage slots modified.

What you get back:

The exact approval being granted (spender address, token, amount), the storage diff confirming the allowance slot changed, and whether the transaction would succeed. Useful any time you’re interacting with an unfamiliar contract or want to verify calldata before signing.

Debug a failed on-chain transaction

What to ask:

“Why did transaction 0x6c5df5a1e6b34e2432ae19706e38a84239495cdbf40c2a9d4d79806443c4aa0d revert on Ethereum?”

What Claude does:

1. Calls trace_transaction with the tx hash. Returns the status (false = reverted), gas used, decoded method name, and error message.
2. Calls get_simulation_call_trace to get the full internal call tree — every function call, with decoded names, inputs, outputs, and which specific call failed.
3. Calls get_simulation_events to see what events were emitted before the revert point.
4. Optionally calls get_simulation_state_changes to see what state was modified up to the failure.

What you get back:

A clear explanation of exactly which internal call failed, the decoded revert reason (e.g., "ERC20: transfer amount exceeds balance"), and the full call trace so you can see the execution path leading up to the failure.

Re-simulate a failed transaction with a fix

What to ask:

“Transaction 0x… failed with ‘ERC20: transfer amount exceeds balance’. Re-simulate it but override my USDC balance to 10,000 USDC to confirm that’s the only issue.”

What Claude does:

1. Calls resimulate_transaction with the original tx hash and a state override setting your token balance to 10,000 USDC.
2. If the simulation succeeds, confirms the root cause was insufficient balance.
3. Calls get_simulation_call_trace to verify the execution path now completes without error.
4. Optionally calls get_simulation_asset_transfers to show what the transaction would have done if it had succeeded.

What you get back:

Confirmation of whether the fix resolves the issue, without deploying anything or spending gas. State overrides let you test assumptions — insufficient balance, wrong allowance, incorrect ownership — instantly, against real mainnet state.

Understand what a transaction did

What to ask:

“Walk me through everything that happened in transaction 0x… on Ethereum — every internal call, who called who, and what changed.”

What Claude does:

1. Calls trace_transaction for a top-level summary: method name, sender, recipient, gas used, and status.
2. Calls get_simulation_call_trace to get the full internal call tree — every nested call with decoded function names, inputs, outputs, and per-call gas.
3. Calls get_simulation_events to list all events emitted in order.
4. Calls get_simulation_state_changes to show every storage slot and balance that changed.

What you get back:

A complete, human-readable reconstruction of the transaction. Useful for auditing unfamiliar protocol interactions, understanding MEV activity, or verifying that a complex multi-contract call did exactly what you expected.

Inspect a smart contract

What to ask:

“What contract is deployed at 0xdAC17F958D2ee523a2206206994597C13D831ec7 on Ethereum?”

What Claude does:

1. Calls get_contract_info with the address and Ethereum’s network ID.

What you get back:

The contract name (Tether USD), token standards (ERC-20), compiler version, EVM version, source language, creation block, deployer address, creation transaction hash, and the full ABI. Claude can then use the ABI to help you encode calldata for simulations or build transactions.

Send an impersonated transaction on a VNet and trace it

What to ask:

“On my VNet, send a transaction from the Uniswap V2 deployer 0x1a9C8182C09F50C8318d769245beA52c32BE35BC to the USDC contract 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 calling the transfer function to send 1000 USDC to my wallet. Then trace the execution.”

What Claude does:

1. Calls send_vnet_transaction with the deployer as from, USDC as to, and the ABI-encoded transfer calldata. The sender is impersonated — no private key needed.
2. Calls get_vnet_transactions to get the operation_id of the executed transaction.
3. Calls trace_vnet_transaction to get the decoded execution summary — contract name, function name, decoded input parameters, and output.
4. Optionally calls get_vnet_simulation_events and get_vnet_simulation_state_changes for deeper details.

What you get back:

Confirmation that the transaction executed, the decoded trace showing the transfer call succeeded, and the events emitted (Transfer event with your wallet as recipient).

Test a multi-step contract interaction on a VNet

What to ask:

“On my VNet, run the full approval and swap flow: first approve the Uniswap router to spend 1000 USDC from my wallet, then execute the swap. Show me my balances before and after.”

What Claude does:

1. Calls send_vnet_transaction to submit the approve transaction, impersonating your wallet — no private key needed.
2. Calls send_vnet_transaction again with the swap calldata.
3. Calls get_vnet_simulation_asset_changes on each transaction to show token movements per step.
4. Calls get_vnet_simulation_balance_changes after the final step to show the net balance impact.

What you get back:

Step-by-step confirmation that each transaction succeeded, token transfers per step, and your final net balance change. This is the full pre-deployment testing loop — run any sequence of transactions against a forked mainnet state before touching real funds.

Analyze gas usage for optimization

What to ask:

“Simulate this transaction and show me a gas breakdown so I can find the most expensive function calls: [paste calldata or describe the transaction]“

What Claude does:

1. Calls simulate_transaction with your transaction parameters.
2. Calls get_simulation_gas_breakdown to get per-call gas consumption including intrinsic gas and refunds.
3. Calls get_simulation_call_trace to map gas costs to specific function calls in the execution tree.

What you get back:

A ranked list of the most gas-expensive operations, mapped to specific function calls. Use this to identify which parts of your contract logic to optimize.

Fork a VNet for parallel testing

What to ask:

“Fork my current VNet so I can test a different approach without losing the current state.”

What Claude does:

1. Calls list_vnets to find your current VNet.
2. Calls fork_vnet with the VNet ID, creating a new VNet with all state preserved — deployed contracts, balances, and transaction history.
3. Returns the new VNet details with fresh RPC URLs.

What you get back:

Two independent VNets sharing the same starting state. You can test different contract changes or transaction sequences in each without interference — like branching in git, but for blockchain state.