simulate_transaction
Simulate an EVM transaction before anyone signs it, and report whether it would succeed. Runs `eth_call` (and a trace where the RPC supports one) against the chain's own RPC — it never signs and never sends, so it is safe against a mainnet endpoint. Returns either success with the balance changes and the emitted events, or a failure with the node's own revert reason. A revert is never reported as a success. The `from` address matters: an `eth_call` runs against that account's state, so simulate from the wallet the user will actually sign with or the answer is about the wrong account. Use this to check a transaction before handing it to a user for approval; the signing tools run the same check automatically and attach the result as the `simulation` on the returned `TxRequest`.
Simulate an EVM transaction before anyone signs it, and report whether it would succeed. Runs eth_call (and a trace where the RPC supports one) against the chain's own RPC — it never signs and never sends, so it is safe against a mainnet endpoint.
Input
The tool takes a single JSON object. Every field, its type, and an example are on the generated reference at GET /mcp/tools, under this tool's name.
Calling it
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": { "name": "simulate_transaction", "arguments": {} }
}Put your arguments in place of the empty object. A call that fails comes back as a normal result carrying isError: true and a message naming what went wrong, not as a JSON-RPC protocol error.
Notes
Returns either success with the balance changes and the emitted events, or a failure with the node's own revert reason. A revert is never reported as a success. The from address matters: an eth_call runs against that account's state, so simulate from the wallet the user will actually sign with or the answer is about the wrong account. Use this to check a transaction before handing it to a user for approval; the signing tools run the same check automatically and attach the result as the simulation on the returned TxRequest.
The full request and response shape, and a live playground, live on the generated reference at GET /mcp/tools.
Transactions
Simulate a transaction, and read what happened to a signing request.
tx_request_status
Read one signing request by id and see what happened to it. Call this after any value-moving tool: that tool returns a `TxRequest` with a `status` of `pending` and a `summary` of what the transaction would do, and this is how you learn whether the user signed, whether the transaction confirmed onchain, or whether it reverted. Works for both kinds of caller — a dashboard user polling a request the website is showing, and an external agent polling one it created with an `sk-` key. putty never signs: you sign with your own wallet and report the hash with `POST /tx-requests/{id}/submitted` (or the dashboard posts it for you). A request owned by another user answers exactly as a request that does not exist, so a wrong id is indistinguishable from a missing one.