# Table of Contents

- [MCP Server | Tenderly Documentation](#mcp-server-tenderly-documentation)
- [MCP Server Quickstart | Tenderly Documentation](#mcp-server-quickstart-tenderly-documentation)
- [MCP Server Tools Reference | Tenderly Documentation](#mcp-server-tools-reference-tenderly-documentation)
- [MCP Server Examples | Tenderly Documentation](#mcp-server-examples-tenderly-documentation)

---

# MCP Server | Tenderly Documentation

### Platform

### Virtual TestNets

### Node RPC

### Simulation API

### Developer Explorer

### Monitoring

### AI Tools

### Resources

MCP Server

Overview

MCP Server
==========

The Tenderly MCP Server gives AI assistants direct access to Tenderly’s platform — creating Virtual TestNets, simulating transactions, tracing execution, inspecting contracts, and more. Use natural language in Claude to drive your entire smart contract development workflow.

The MCP Server requires a [Tenderly account](https://dashboard.tenderly.co/register)
 and at least one project.

Get started[](https://docs.tenderly.co/mcp-server#get-started)

---------------------------------------------------------------

  

[Quickstart→](https://docs.tenderly.co/mcp-server/quickstart)
[Tools Reference→](https://docs.tenderly.co/mcp-server/tools)
[Examples→](https://docs.tenderly.co/mcp-server/examples)

What is MCP?[](https://docs.tenderly.co/mcp-server#what-is-mcp)

----------------------------------------------------------------

The [Model Context Protocol (MCP)](https://modelcontextprotocol.io/)
 is an open standard by Anthropic that lets AI models connect to external tools and data sources. Instead of copy-pasting RPC responses or writing curl commands, Claude can call Tenderly tools directly — live blockchain data, transaction simulation, debugging, and Virtual TestNet management all happen within the conversation.

Capabilities[](https://docs.tenderly.co/mcp-server#capabilities)

-----------------------------------------------------------------

The MCP Server exposes **33 tools** across six areas:

*   **Virtual TestNets** — Create, fork, and manage private blockchain environments. Fund accounts, send impersonated transactions, and list transaction history.
*   **Transaction Simulation** — Simulate any transaction on any supported EVM network without spending gas. Get decoded call traces, events, state changes, asset transfers, and balance diffs.
*   **Transaction Tracing** — Trace on-chain and VNet transactions with full execution details. Inspect call trees, gas breakdown, state diffs, and EIP-2930 access lists.
*   **Contract Inspection** — Retrieve contract metadata for any address — name, ABI, compiler version, token standards, and creation info.
*   **Network Discovery** — List all 100+ EVM networks Tenderly supports.
*   **Project Management** — List projects and set the active project context.

See the full [Tools Reference](https://docs.tenderly.co/mcp-server/tools)
 for details on every tool.

Supported clients[](https://docs.tenderly.co/mcp-server#supported-clients)

---------------------------------------------------------------------------

The Tenderly MCP Server works with any MCP-compatible client:

*   **Claude Code** — Add via CLI with one command
*   **Claude.ai** — Connect through Settings → Connectors
*   **Claude Desktop** — Connect through Settings → Connectors
*   **Cursor/VS Code** — Add the server URL to your MCP config

See the [Quickstart](https://docs.tenderly.co/mcp-server/quickstart)
 for setup instructions for each client.

Authentication[](https://docs.tenderly.co/mcp-server#authentication)

---------------------------------------------------------------------

The MCP Server uses OAuth 2.0 via [WorkOS](https://workos.com/)
. When you connect from Claude, you’ll be redirected to Tenderly to log in and authorize access. Claude can only perform actions within the scope of your permissions.

Revoke access at any time by disconnecting the connector in Claude.

[Quickstart](https://docs.tenderly.co/mcp-server/quickstart "Quickstart")

---

# MCP Server Quickstart | Tenderly Documentation

### Platform

### Virtual TestNets

### Node RPC

### Simulation API

### Developer Explorer

### Monitoring

### AI Tools

### Resources

MCP Server

Quickstart

Quickstart
==========

Get the Tenderly MCP Server running in your AI assistant in under a minute.

Prerequisites[](https://docs.tenderly.co/mcp-server/quickstart#prerequisites)

------------------------------------------------------------------------------

*   A [Tenderly account](https://dashboard.tenderly.co/register)
     (Free, Developer, or Pro plan)
*   At least one Tenderly project

Connect to the MCP Server[](https://docs.tenderly.co/mcp-server/quickstart#connect-to-the-mcp-server)

------------------------------------------------------------------------------------------------------

Claude CodeClaude.aiClaude DesktopCursor / VS Code

Run the following command in your terminal:

    claude mcp add tenderly --transport http https://mcp.tenderly.co/mcp

Verify the server is connected:

    claude mcp list

Run `/mcp` inside Claude Code, select **tenderly**, and follow the browser login to authenticate.

First tool call[](https://docs.tenderly.co/mcp-server/quickstart#first-tool-call)

----------------------------------------------------------------------------------

Once connected, try a simple prompt to verify everything works:

> “What is my account name and currently active project?”

Claude will call `get_user_info` and returns your account information and the currently active project (if set). If this works, you’re all set.

Set your active project[](https://docs.tenderly.co/mcp-server/quickstart#set-your-active-project)

--------------------------------------------------------------------------------------------------

Most tools require a project context. Set it once per session:

> “Set my active project to my-project under my-account”

Claude will call `set_active_project`. All subsequent tool calls (simulations, VNets, traces) will use this project.

You can also let Claude figure out the project automatically — just ask it to do something and it will call `list_projects` first if needed.

Next steps[](https://docs.tenderly.co/mcp-server/quickstart#next-steps)

------------------------------------------------------------------------

*   [Tools Reference](https://docs.tenderly.co/mcp-server/tools)
    : See all 33 tools and what they do
*   [Examples](https://docs.tenderly.co/mcp-server/examples)
    : Walkthroughs for common workflows
*   [Virtual TestNets](https://docs.tenderly.co/virtual-testnets)
    : Learn more about the environments you can create
*   [Simulations](https://docs.tenderly.co/simulations)
    : Understand how transaction simulation works

[Overview](https://docs.tenderly.co/mcp-server "Overview")
[Tools Reference](https://docs.tenderly.co/mcp-server/tools "Tools Reference")

---

# MCP Server Tools Reference | Tenderly Documentation

### Platform

### Virtual TestNets

### Node RPC

### Simulation API

### Developer Explorer

### Monitoring

### AI Tools

### Resources

MCP Server

Tools Reference

Tools Reference
===============

The Tenderly MCP Server exposes 33 tools organized into six groups. All tools that operate on project resources require an active project — call `set_active_project` first.

You don’t need to call tools by name. Just describe what you want in natural language and Claude will pick the right tools automatically.

Project & account[](https://docs.tenderly.co/mcp-server/tools#project--account)

--------------------------------------------------------------------------------

These tools manage your session context. Most other tools depend on having an active project set.

| Tool | Description |
| --- | --- |
| `get_user_info` | Returns your account info (ID, username, email) and the currently active project if set. |
| `list_projects` | Lists all Tenderly projects accessible to you. Supports optional search filtering by name or slug. |
| `set_active_project` | Sets the active project for subsequent tool calls. Accepts `account_slug` and `project_slug`. Must be called before using project-scoped tools. |

Networks[](https://docs.tenderly.co/mcp-server/tools#networks)

---------------------------------------------------------------

| Tool | Description |
| --- | --- |
| `get_networks` | Lists all public EVM networks supported by Tenderly (100+). Supports optional search filtering by name. Returns network ID, name, slug, and chain ID. |

Contracts[](https://docs.tenderly.co/mcp-server/tools#contracts)

-----------------------------------------------------------------

| Tool | Description |
| --- | --- |
| `get_contract_info` | Retrieves metadata for a contract address on a given network: contract name, ABI (if verified), compiler version, EVM version, language, token standards (ERC-20, ERC-721, etc.), creation block, creation transaction, and deployer address. |

Transaction simulations[](https://docs.tenderly.co/mcp-server/tools#transaction-simulations)

---------------------------------------------------------------------------------------------

Simulate and trace transactions on any Tenderly-supported EVM network without spending gas or modifying on-chain state.

### Core simulation tools[](https://docs.tenderly.co/mcp-server/tools#core-simulation-tools)

| Tool | Description |
| --- | --- |
| `simulate_transaction` | Simulates a transaction and returns the outcome: success/revert status, gas used, decoded method name, error message, and revert reason. Supports state overrides, EIP-1559 fields, and custom block numbers. Results are persisted to your project dashboard. |
| `resimulate_transaction` | Replays an existing on-chain transaction in Tenderly’s simulation environment. Useful for debugging transactions that reverted or behaved unexpectedly. |
| `trace_transaction` | Traces an on-chain transaction and returns a summary: status, gas used, decoded method, sender, recipient, and error details. |

### Simulation detail tools[](https://docs.tenderly.co/mcp-server/tools#simulation-detail-tools)

After running `simulate_transaction`, `resimulate_transaction`, or `trace_transaction`, use these follow-up tools with the returned `simulation_id` or `tx_hash` to inspect specific aspects of the execution.

| Tool | Description |
| --- | --- |
| `get_simulation_call_trace` | Flattened call tree — every internal EVM call with decoded function names, inputs, outputs, and per-call gas. Supports `max_depth` parameter. Capped at 256 entries. |
| `get_simulation_events` | Decoded events (logs) emitted during execution, including event names, emitting addresses, and ABI-decoded parameters. Capped at 100 entries. |
| `get_simulation_state_changes` | Storage slot diffs (address, key, before/after values) and native balance diffs for all affected accounts. Capped at 100 entries. |
| `get_simulation_asset_transfers` | All token and native asset transfers: sender, recipient, token info (name, type, symbol, decimals), and amount. Capped at 100 entries. |
| `get_simulation_exposure_changes` | Token approval and allowance changes — approvals, revocations, and permits. Capped at 100 entries. |
| `get_simulation_balance_changes` | Net per-address balance impact with USD dollar values. Capped at 100 entries. |
| `get_simulation_gas_breakdown` | Per-call gas breakdown including intrinsic gas and refunds. Gas values are inclusive of subcalls. |
| `get_simulation_generated_access_list` | Generates an EIP-2930 access list by re-simulating the transaction. Useful for gas optimization. |

Virtual TestNets[](https://docs.tenderly.co/mcp-server/tools#virtual-testnets)

-------------------------------------------------------------------------------

Create and manage private, persistent forks of public EVM networks. Virtual TestNets have their own RPC endpoints and support impersonated transactions without private keys.

| Tool | Description |
| --- | --- |
| `create_vnet` | Creates a new Virtual TestNet by forking a public network at a specific block. Accepts `network_id`, optional `display_name`, `description`, `block_number` (hex), custom `chain_id`, and `sync_state_enabled`. Returns the VNet details including RPC URLs. |
| `list_vnets` | Lists Virtual TestNets in the active project. Supports pagination (`page`, `per_page`), status filtering (`running`, `stopped`, `cloning`), and search by name. |
| `get_vnet` | Returns full details of a Virtual TestNet: ID, slug, display name, status, description, fork config, chain config, and RPC endpoint URLs. |
| `fork_vnet` | Forks an existing Virtual TestNet into a new one, preserving all state including deployed contracts and balances. |
| `send_vnet_transaction` | Sends and executes a transaction on a Virtual TestNet. The sender address is impersonated — no private key needed. Accepts `from`, `to`, `input` (calldata), `value` (hex wei), and `gas`. |
| `get_vnet_transactions` | Lists transactions executed on a Virtual TestNet with pagination. Returns transaction hash, status, gas used, block number, and method. |
| `fund_account` | Sets the native token balance of any address on a Virtual TestNet by calling `tenderly_setBalance` via RPC. Accepts `address` and `amount` in hex wei. |

Virtual TestNet simulations & traces[](https://docs.tenderly.co/mcp-server/tools#virtual-testnet-simulations--traces)

----------------------------------------------------------------------------------------------------------------------

Simulate and trace transactions on Virtual TestNets specifically. These tools work with VNet IDs and operation IDs rather than network-level tx hashes.

### Core VNet simulation tools[](https://docs.tenderly.co/mcp-server/tools#core-vnet-simulation-tools)

| Tool | Description |
| --- | --- |
| `simulate_vnet_transaction` | Simulates a transaction on a VNet without modifying its state. Returns status, gas used, decoded method, and an `operation_id` for follow-up tools. Supports state overrides. |
| `resimulate_vnet_transaction` | Re-traces a previously executed VNet transaction by its `operation_id` (from `get_vnet_transactions`). |
| `trace_vnet_transaction` | Returns a decoded execution trace summary: contract name, function name, decoded input parameters, decoded output, gas used, and error details. |

### VNet simulation detail tools[](https://docs.tenderly.co/mcp-server/tools#vnet-simulation-detail-tools)

Use these with `vnet_id` and `operation_id` from the tools above.

| Tool | Description |
| --- | --- |
| `get_vnet_simulation_call_trace` | Flattened call trace for a VNet transaction with call type, addresses, gas, and value per call. |
| `get_vnet_simulation_events` | Decoded events emitted during a VNet transaction: event name and emitting address. |
| `get_vnet_simulation_gas_breakdown` | Per-call gas breakdown sorted by gas usage. Shows total gas and top consumers. |
| `get_vnet_simulation_state_changes` | Storage slot diffs: address, key, before/after values for each modified slot. |
| `get_vnet_simulation_generated_access_list` | EIP-2930 access list generated from the VNet transaction execution. |
| `get_vnet_simulation_balance_changes` | Net per-address balance changes with dollar values. |
| `get_vnet_simulation_asset_changes` | Token and native asset transfers: type, from, to, amount, and token info. |

[Quickstart](https://docs.tenderly.co/mcp-server/quickstart "Quickstart")
[Examples](https://docs.tenderly.co/mcp-server/examples "Examples")

---

# MCP Server Examples | Tenderly Documentation

### Platform

### Virtual TestNets

### Node RPC

### Simulation API

### Developer Explorer

### Monitoring

### AI Tools

### Resources

MCP Server

Examples

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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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[](https://docs.tenderly.co/mcp-server/examples#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.

Use `get_simulation_generated_access_list` to generate an EIP-2930 access list, which can reduce gas costs by pre-declaring which storage slots and addresses the transaction will access.

* * *

Fork a VNet for parallel testing[](https://docs.tenderly.co/mcp-server/examples#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.

[Tools Reference](https://docs.tenderly.co/mcp-server/tools "Tools Reference")

---