> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tenderly.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Примеры использования MCP Server

> Пошаговые сценарии типичных рабочих процессов с использованием Tenderly MCP Server и Claude.

Эти сценарии показывают, как Claude использует инструменты [Tenderly MCP Server](/ai-tools/overview), чтобы выполнять реальные задачи разработки. Если вы ещё не подключили сервер, сначала следуйте [быстрому старту MCP Server](/ai-tools/quickstart). Вам не нужно вызывать инструменты по имени — просто опишите, что хотите, и Claude сделает всё остальное.

Примеры примерно сгруппированы по видам деятельности:

* **Настройка и pre-flight**: разворачивание сред, пополнение кошельков, проверка транзакций перед подписью.
* **Отладка и post-mortem**: выяснение, почему транзакция упала, кто забрал средства или почему swap вернул меньше, чем ожидалось. Здесь особенно полезны инструменты продвинутой навигации по трассе.
* **Сценарии в Virtual Environment**: имперсонация, многошаговое тестирование, снапшоты, путешествия во времени, переопределение балансов токенов.
* **Оптимизация и инспекция**: разбивка газа, метаданные контрактов.

## Создание Virtual Environment и пополнение кошелька

**Что попросить:**

> "Создай Virtual Environment, форкнутый из Ethereum mainnet, и пополни мой кошелёк 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 на 100 ETH."

**Что делает Claude:**

1. Вызывает `list_projects`, чтобы найти ваши проекты, затем `set_active_project`, чтобы выбрать один.
2. Вызывает `get_networks`, чтобы найти network ID для Ethereum mainnet.
3. Вызывает `create_vnet` с network ID, создавая форкнутую среду. Новый Virtual Environment автоматически становится активным.
4. Вызывает `fund_account` с адресом вашего кошелька, устанавливая баланс 100 ETH в hex wei. Работает автоматически с активным Virtual Environment.
5. Возвращает детали Virtual Environment, включая URL **Admin RPC** и **Public RPC**, готовые для использования в Hardhat, Foundry или любой Web3-библиотеке.

**Что вы получаете:**

Запущенный Virtual Environment, форкнутый из последнего состояния mainnet, пополненный кошелёк и RPC URL, которые можно подставить в конфиг вашего фреймворка разработки.

***

## Симуляция swap на Uniswap

**Что попросить:**

> "Симулируй swap 1 ETH на USDC в Uniswap V3 от 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 в Ethereum mainnet. Покажи ожидаемый выход и все переводы токенов."

**Что делает Claude:**

1. Вызывает `simulate_transaction` с адресом роутера Uniswap V3, адресом отправителя, calldata swap и 1 ETH в качестве value.
2. Симуляция запускается на текущем состоянии mainnet и возвращает: статус success/revert, использованный газ и декодированное имя метода.
3. Вызывает `get_simulation_asset_transfers`, чтобы показать все движения токенов — ETH на вход и USDC на выход.
4. Вызывает `get_simulation_balance_changes`, чтобы показать чистое влияние на балансы с USD-значениями.

**Что вы получаете:**

Точный выход USDC, стоимость газа и разбивку каждого перевода активов. Если swap упал бы (например, из-за слишком высокого slippage), вы получите декодированную причину revert.

***

## Pre-flight проверка транзакции перед отправкой

**Что попросить:**

> "Я собираюсь вызвать `approve` на 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, чтобы дать 0xE592427A0AEce92De3Edee1F18E0157C05861564 безлимитное allowance USDC. Симулируй сначала и покажи, какие approvals и изменения состояния это создаст."

**Что делает Claude:**

1. Вызывает `simulate_transaction` с вашим кошельком как отправителем, контрактом токена как получателем и calldata `approve`.
2. Вызывает `get_simulation_exposure_changes`, чтобы показать каждое изменение approvals и allowance — кто получает доступ, к чему и в каком объёме.
3. Вызывает `get_simulation_state_changes`, чтобы показать точные слоты хранилища, которые изменились.

**Что вы получаете:**

Точный выданный approval (адрес spender, токен, сумма), дифф хранилища, подтверждающий изменение слота allowance, и статус успешности транзакции. Полезно каждый раз, когда вы взаимодействуете с незнакомым контрактом или хотите проверить calldata перед подписью.

***

## Отладка упавшей ончейн-транзакции

**Что попросить:**

> "Почему транзакция 0x6c5df5a1e6b34e2432ae19706e38a84239495cdbf40c2a9d4d79806443c4aa0d упала в Ethereum?"

**Что делает Claude:**

1. Вызывает `trace_transaction` с хешем транзакции. Возвращает статус (`false` = revert), использованный газ, декодированное имя метода и сообщение об ошибке.
2. Вызывает `get_simulation_call_trace`, чтобы получить полное внутреннее дерево вызовов — каждый вызов функции с декодированными именами, входами, выходами и указанием, какой конкретно вызов упал.
3. Вызывает `get_simulation_events`, чтобы увидеть, какие события были эмитированы до точки revert.
4. Опционально вызывает `get_simulation_state_changes`, чтобы увидеть, какое состояние было изменено до падения.

**Что вы получаете:**

Ясное объяснение, какой именно внутренний вызов упал, декодированную причину revert (например, `"ERC20: transfer amount exceeds balance"`) и полную трассу вызовов, чтобы увидеть путь исполнения, приведший к падению.

***

## Поиск первопричины revert в глубоко вложенной транзакции

**Что попросить:**

> "Транзакция 0x... упала в Ethereum. Это сложный DeFi-вызов с массой внутренних вызовов, найди фактическую ошибку и покажи путь, который к ней привёл."

**Что делает Claude:**

1. Вызывает `trace_transaction` для верхнеуровневой сводки и подтверждает revert.
2. Вызывает `find_failures`, чтобы перечислить все упавшие вызовы в транзакции, а не только самый внешний. Это показывает как первоначальный revert, так и оборачивающие `require`/try-catch-падения.
3. Вызывает `get_error_path`, чтобы вернуть цепочку виновников от корневого вызова вниз до самого глубокого упавшего вызова, с декодированными входами и выходами на каждом уровне.
4. Если у какого-то узла всё ещё есть опущенные потомки, вызывает `get_call_trace_node` для конкретной позиции, чтобы развернуть его.

**Что вы получаете:**

Точный контракт, функцию и декодированную причину revert на самой глубокой точке падения, плюс полную цепочку вызывающих, которая к ней привела. Гораздо быстрее, чем листать вывод `get_simulation_call_trace` из 200 вызовов.

***

## Навигация по очень большой трассе

**Что попросить:**

> "У этой транзакции сотни внутренних вызовов, и `get_simulation_call_trace` усечён. Помоги мне понять её структуру и углубиться в важную часть."

**Что делает Claude:**

1. Вызывает `get_trace_stats`, чтобы сообщить общее число вызовов, максимальную глубину, количество ошибок и уникальных контрактов — быстрая проверка размера, которая определяет стратегию.
2. Вызывает `get_trace_skeleton`, чтобы получить сжатое дерево вызовов: имя функции, контракт, глубина и флаг ошибки для каждого узла, без декодированных аргументов.
3. Определяет интересующее поддерево (падающая ветвь, конкретный протокол или подозрительный контракт) по значениям `absolute_position` из скелета.
4. Вызывает `get_call_trace_node`, чтобы развернуть это поддерево с полными декодированными входами и выходами.
5. Опционально вызывает `get_subtree_events` и `get_subtree_state_changes`, чтобы увидеть только события и диффы хранилища из этого поддерева.

**Что вы получаете:**

Карту структуры транзакции, а затем полные детали только той её части, которая вас интересует, без загрузки тысяч вызовов в контекст.

***

## Поиск в трассе конкретного контракта или функции

**Что попросить:**

> "Вызывалась ли `transferFrom` на USDC в этой транзакции? Если да, покажи каждый такой вызов с декодированными аргументами."

**Что делает Claude:**

1. Вызывает `search_call_trace` с адресом USDC и `transferFrom` в качестве фильтров, возвращая только совпадающие вызовы с их декодированными входами, выходами и абсолютными позициями.
2. Для интересных совпадений вызывает `get_call_trace_node`, чтобы получить полный вложенный контекст вокруг.

**Что вы получаете:**

Точечный список совпадающих вызовов вместо полной трассы. Полезно для ответа на вопросы "случилось ли X" в больших транзакциях и для аудита, вызывался ли известный рискованный selector.

***

## Отслеживание денег в транзакции

**Что попросить:**

> "Для транзакции 0x... в Ethereum покажи, кто, что и кому отправлял по порядку, с USD-значениями."

**Что делает Claude:**

1. Вызывает `get_transaction_fund_flow` с хешем транзакции. Возвращает упорядоченные переводы токенов и нативных активов, каждый с адресами from/to и USD-значениями, плюс чистый поток по каждому адресу.
2. Опционально вызывает `get_contract_info` для незнакомых адресов, чтобы идентифицировать их (роутер протокола, пул, treasury и т. д.).

**Что вы получаете:**

Хронологическую денежную карту транзакции и чистый поток по адресам — идеально для понимания MEV-бандлов, незнакомых DeFi-взаимодействий или проверки, что multi-hop swap двигал средства как ожидалось. Только для ончейн-транзакций.

***

## Отладка упавшего batch-исполнения Safe multisig

**Что попросить:**

> "Наше batch-исполнение Safe в 0x... упало в Ethereum. В batch 12 вызовов. Какой из них на самом деле упал и почему?"

**Что делает Claude:**

1. Вызывает `trace_transaction`, чтобы подтвердить revert и получить верхнеуровневый метод (`execTransaction` или `multiSend`).
2. Вызывает `get_trace_stats` — batch'и Safe быстро превращаются в большие трассы, так что статистика определяет следующий шаг.
3. Вызывает `find_failures`: поскольку `multiSend` часто откатывает весь batch при падении любого подвызова, это самый быстрый способ увидеть, какая из 12 операций взорвалась, а не только внешний revert Safe.
4. Вызывает `get_error_path` для упавшего подвызова, чтобы получить полную декодированную цепочку input/output на каждом уровне.
5. Опционально вызывает `get_call_trace_node`, если какой-то важный узел был усечён.

**Что вы получаете:**

Точный подвызов внутри batch, который упал, с декодированной целью, функцией, аргументами и причиной revert — вместо общей ошибки "GS013" Safe без контекста.

***

## Post-mortem эксплойта или подозрительной транзакции

**Что попросить:**

> "0x... в Ethereum вывел средства из нашего протокола. Проведи меня по тому, что произошло: у кого оказались деньги, что вызывал атакующий и где эксплойт зашёл в наши контракты."

**Что делает Claude:**

1. Сначала вызывает `get_transaction_fund_flow` — упорядоченные переводы токенов и нативных активов плюс чистый поток по каждому адресу сразу выявляют кошелёк атакующего и опустошённые адреса протокола.
2. Вызывает `get_trace_skeleton`, чтобы отобразить структуру вызовов атакующего без загрузки всех аргументов.
3. Вызывает `search_call_trace` для вызовов в контракты протокола (по адресу), чтобы изолировать точку входа.
4. Вызывает `get_call_trace_node` в точке входа для декодированных аргументов, затем `get_subtree_state_changes`, чтобы увидеть, какое именно состояние мутировал эксплойт.
5. Вызывает `get_contract_info` для любых неизвестных контрактов, с которыми взаимодействовал атакующий (хелперы, прокси, известные контракты эксплойтов).

**Что вы получаете:**

Повествование эксплойта с фокусом на деньгах: кто что получил, точная функция и аргументы, спровоцировавшие вывод, и изменения состояния, которые сделали это возможным. Достаточно деталей, чтобы написать incident report или начать патч.

***

## Расследование неожиданной ликвидации

**Что попросить:**

> "Мою позицию в Aave ликвидировали в 0x..., выясни почему. Хочу знать цену оракула в момент ликвидации и точный путь health factor."

**Что делает Claude:**

1. Вызывает `trace_transaction` и `get_trace_skeleton`, чтобы отобразить дерево вызовов ликвидации.
2. Вызывает `search_call_trace` для вызовов оракула (например, `latestAnswer`, `getAssetPrice`), чтобы найти чтения цены, использованные ликвидацией.
3. Вызывает `get_call_trace_node` для каждого совпадения, чтобы получить декодированные возвращаемые значения — точную цену, питающую расчёт health factor.
4. Вызывает `get_transaction_fund_flow`, чтобы показать, сколько collateral было изъято, сколько долга погашено и какой бонус получил ликвидатор.
5. Опционально вызывает `get_subtree_events` для поддерева ликвидации — события `LiquidationCall` и `Transfer` по порядку.

**Что вы получаете:**

Использованные цены оракулов, прибыль ликвидатора, точные суммы collateral и долга, и, если применимо, блок или транзакцию, которая уронила ваш health factor ниже 1. Полный ответ на вопрос "почему меня ликвидировали".

***

## Аудит swap через 1inch / агрегатор, который вернул меньше, чем ожидалось

**Что попросить:**

> "0x... — это swap через 1inch, где я получил значительно меньше USDC, чем в котировке. Какой пул или hop дал плохую цену?"

**Что делает Claude:**

1. Вызывает `get_trace_stats` — маршруты агрегатора могут быть глубокими со многими hop'ами через пулы.
2. Вызывает `get_trace_skeleton`, чтобы увидеть последовательность вызовов пулов по порядку.
3. Вызывает `search_call_trace` для `swap`, `exactInput` или селекторов взаимодействия с пулами роутера, вытаскивая каждый hop.
4. Вызывает `get_call_trace_node` для каждого hop'а, чтобы получить декодированные значения `amountIn` / `amountOut`.
5. Вызывает `get_transaction_fund_flow`, чтобы подтвердить итоговое чистое полученное и любые неожиданные переводы (комиссии, ребейты).

**Что вы получаете:**

Разбивку входных и выходных сумм по каждому hop'у в маршруте с указанием пула, где исполнение оказалось хуже ожидаемого. Полезно для измерения slippage, сравнения маршрутов или ловли проблем с устаревшими котировками.

***

## Пересимуляция упавшей транзакции с исправлением

**Что попросить:**

> "Транзакция 0x... упала с 'ERC20: transfer amount exceeds balance'. Пересимулируй её, но переопредели мой баланс USDC на 10 000 USDC, чтобы подтвердить, что это единственная проблема."

**Что делает Claude:**

1. Вызывает `resimulate_transaction` с оригинальным хешем транзакции и переопределением состояния, устанавливающим ваш баланс токена в 10 000 USDC.
2. Если симуляция проходит, подтверждает, что корневая причина — недостаточный баланс.
3. Вызывает `get_simulation_call_trace`, чтобы проверить, что путь исполнения теперь завершается без ошибки.
4. Опционально вызывает `get_simulation_asset_transfers`, чтобы показать, что бы сделала транзакция, если бы прошла.

**Что вы получаете:**

Подтверждение того, устраняет ли исправление проблему, без деплоя и трат газа. Переопределения состояния позволяют мгновенно проверять предположения — недостаточный баланс, неправильное allowance, некорректный owner — на реальном состоянии mainnet.

***

## Понимание того, что сделала транзакция

**Что попросить:**

> "Проведи меня по всему, что произошло в транзакции 0x... в Ethereum, каждый внутренний вызов, кто кого вызывал и что изменилось."

**Что делает Claude:**

1. Вызывает `trace_transaction` для верхнеуровневой сводки: имя метода, отправитель, получатель, использованный газ и статус.
2. Вызывает `get_simulation_call_trace`, чтобы получить полное внутреннее дерево вызовов — каждый вложенный вызов с декодированными именами функций, входами, выходами и газом по каждому вызову.
3. Вызывает `get_simulation_events`, чтобы перечислить все эмитированные события по порядку.
4. Вызывает `get_simulation_state_changes`, чтобы показать каждый слот хранилища и баланс, которые изменились.

**Что вы получаете:**

Полную, понятную человеку реконструкцию транзакции. Полезно для аудита незнакомых взаимодействий с протоколами, понимания MEV-активности или проверки, что сложный вызов с несколькими контрактами сделал именно то, что вы ожидали.

***

## Инспекция смарт-контракта

**Что попросить:**

> "Какой контракт задеплоен по адресу 0xdAC17F958D2ee523a2206206994597C13D831ec7 в Ethereum?"

**Что делает Claude:**

1. Вызывает `get_contract_info` с адресом и network ID Ethereum.

**Что вы получаете:**

Имя контракта (Tether USD), стандарты токенов (ERC-20), версию компилятора, EVM-версию, язык исходников, блок создания, адрес деплойера, хеш транзакции создания и полный ABI. Затем Claude может использовать ABI, чтобы помочь вам закодировать calldata для симуляций или собрать транзакции.

***

## Отправка имперсонированной транзакции в Virtual Environment и её трассировка

**Что попросить:**

> "В моём Virtual Environment отправь транзакцию от деплойера Uniswap V2 0x1a9C8182C09F50C8318d769245beA52c32BE35BC на контракт USDC 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, вызывающую функцию `transfer`, чтобы отправить 1000 USDC на мой кошелёк. Затем протрассируй исполнение."

**Что делает Claude:**

1. Вызывает `send_vnet_transaction` в активном Virtual Environment с деплойером как `from`, USDC как `to` и calldata `transfer`, закодированной по ABI. Отправитель имперсонируется, приватный ключ не нужен.
2. Вызывает `get_vnet_transactions`, чтобы получить `operation_id` выполненной транзакции.
3. Вызывает `trace_vnet_transaction`, чтобы получить декодированную сводку исполнения — имя контракта, имя функции, декодированные входные параметры и выход.
4. Опционально вызывает `get_vnet_simulation_events` и `get_vnet_simulation_state_changes` для более глубоких деталей.

**Что вы получаете:**

Подтверждение того, что транзакция выполнилась, декодированную трассу, показывающую успешный вызов `transfer`, и эмитированные события (событие Transfer с вашим кошельком в качестве получателя).

***

## Тестирование многошагового взаимодействия с контрактом в Virtual Environment

**Что попросить:**

> "В моём Virtual Environment пройди полный цикл approval и swap: сначала одобри роутер Uniswap на трату 1000 USDC с моего кошелька, затем выполни swap. Покажи мои балансы до и после."

**Что делает Claude:**

1. Вызывает `send_vnet_transaction` в активном Virtual Environment, чтобы отправить транзакцию `approve`, имперсонируя ваш кошелёк — приватный ключ не нужен.
2. Ещё раз вызывает `send_vnet_transaction` с calldata swap.
3. Вызывает `get_vnet_simulation_asset_changes` для каждой транзакции, чтобы показать движения токенов на каждом шаге.
4. Вызывает `get_vnet_simulation_balance_changes` после последнего шага, чтобы показать чистое изменение баланса.

**Что вы получаете:**

Пошаговое подтверждение успешности каждой транзакции, переводы токенов на каждом шаге и итоговое чистое изменение баланса. Это полный цикл тестирования до деплоя — запустите любую последовательность транзакций на форкнутом состоянии mainnet до того, как трогать реальные средства.

***

## Анализ использования газа для оптимизации

**Что попросить:**

> "Симулируй эту транзакцию и покажи разбивку газа, чтобы я мог найти самые дорогие вызовы функций: \[вставьте calldata или опишите транзакцию]"

**Что делает Claude:**

1. Вызывает `simulate_transaction` с параметрами вашей транзакции.
2. Вызывает `get_simulation_gas_breakdown`, чтобы получить потребление газа по каждому вызову, включая intrinsic gas и refunds.
3. Вызывает `get_simulation_call_trace`, чтобы связать стоимость газа с конкретными вызовами функций в дереве исполнения.

**Что вы получаете:**

Ранжированный список самых газоёмких операций, привязанных к конкретным вызовам функций. Используйте это, чтобы определить, какие части логики вашего контракта стоит оптимизировать.

<Note>
  Используйте `get_simulation_generated_access_list`, чтобы сгенерировать access list EIP-2930, который может снизить стоимость газа за счёт заранее объявленных слотов хранилища и адресов, к которым обратится транзакция.
</Note>

***

## Форк Virtual Environment для параллельного тестирования

**Что попросить:**

> "Форкни мой текущий Virtual Environment, чтобы я мог протестировать другой подход, не теряя текущее состояние."

**Что делает Claude:**

1. Вызывает `list_vnets`, чтобы найти ваш текущий Virtual Environment, затем при необходимости `set_active_vnet`.
2. Вызывает `fork_vnet`, создавая новый Virtual Environment со всем сохранённым состоянием — задеплоенными контрактами, балансами и историей транзакций. Форк автоматически становится активным.
3. Возвращает детали нового Virtual Environment со свежими RPC URL.

**Что вы получаете:**

Два независимых Virtual Environment с одинаковым начальным состоянием. Вы можете тестировать разные изменения контрактов или последовательности транзакций в каждом без взаимных помех — как ветвление в git, но для состояния блокчейна.

***

## Снапшот, тестирование и откат для стресс-тестирования

**Что попросить:**

> "В моём Virtual Environment сделай снапшот текущего состояния, затем симулируй ликвидацию в Aave с разными ценами оракула. Откатывайся к снапшоту между попытками, чтобы я мог сравнить исходы."

**Что делает Claude:**

1. Вызывает `snapshot_vnet`, чтобы сохранить текущее состояние Virtual Environment, получая ID снапшота.
2. Вызывает `set_storage_at`, чтобы переопределить цену оракула на конкретное значение.
3. Вызывает `send_vnet_transaction`, чтобы запустить ликвидацию.
4. Вызывает `get_vnet_simulation_balance_changes` и `get_vnet_simulation_asset_changes`, чтобы зафиксировать исход.
5. Вызывает `revert_vnet`, чтобы восстановить Virtual Environment к состоянию снапшота (снапшот расходуется).
6. Снова вызывает `snapshot_vnet` для следующей итерации, устанавливает другую цену оракула и повторяет.

**Что вы получаете:**

Сравнение исходов ликвидации бок о бок при разных ценовых сценариях, всё тестируется на реальном форкнутом состоянии, без деплоя и влияния на другие тесты.

***

## Установка балансов ERC-20 для тестирования

**Что попросить:**

> "В моём Virtual Environment дай моему кошельку 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 баланс 10 000 USDC и 5 WETH, чтобы я мог протестировать swap."

**Что делает Claude:**

1. Вызывает `set_erc20_balance` с адресом токена USDC, вашим кошельком и нужным количеством.
2. Ещё раз вызывает `set_erc20_balance` с адресом токена WETH и количеством.
3. Опционально вызывает `vnet_call` с вызовом `balanceOf`, чтобы проверить, что балансы установлены корректно.

**Что вы получаете:**

Ваш кошелёк, пополненный точными количествами токенов, готов к тестированию. Это проще, чем считать слоты хранилища вручную — `set_erc20_balance` автоматически учитывает раскладку хранилища токена.

***

## Путешествие во времени для тестирования timelock'ов и vesting

**Что попросить:**

> "В моём Virtual Environment продвинь часы на 7 дней вперёд, чтобы протестировать, корректно ли разблокируется мой timelock-контракт."

**Что делает Claude:**

1. Вызывает `increase_time` с 604800 секундами (7 дней), чтобы продвинуть часы Virtual Environment.
2. Вызывает `mine_block`, чтобы зафиксировать изменение времени в новом блоке.
3. Вызывает `vnet_call`, чтобы прочитать состояние timelock-контракта (например, `isUnlocked()` или `releaseTime()`).
4. Опционально вызывает `send_vnet_transaction`, чтобы выполнить разблокировку и убедиться в её успехе.

**Что вы получаете:**

Подтверждение того, разблокируется ли timelock после прыжка во времени, без ожидания 7 реальных дней. Используйте это для любой логики, зависящей от времени: расписания vesting, периодов голосования в governance, накопления процентов или окон cooldown.