How AI agents talk to blockchains with MCP and RPC

Key takeaways

• A single agent reasoning step typically generates three to seven RPC calls. Multi-step workflows compound that load — which is why the node API layer, not the LLM, is usually the bottleneck in production agentic Web3 systems.
• The node API layer splits across two interfaces that coexist: raw JSON-RPC for the hot path of reads, writes, and event subscriptions, and MCP (Model Context Protocol) for tool discovery, documentation lookup, and node lifecycle operations the agent invokes autonomously.
• A practical walkthrough of a stablecoin treasury agent follows below, showing one full reasoning cycle from LLM prompt to on-chain transaction — including realistic RU consumption for production-scale deployment.

What an agentic Web3 workflow actually is

An agentic Web3 workflow is a sequence in which an LLM-driven agent uses blockchain node APIs to read on-chain state, reason about it, and write transactions back to the chain — repeating the cycle until a goal is met.

That sentence is dense, so unpack it: there is an LLM, there is a goal, there is a node API layer between the LLM and the chain, and there is a loop. The loop is what makes the workflow agentic rather than scripted. A scripted bot follows a fixed sequence. An agentic workflow lets the LLM decide what to do next based on what it just learned from the chain.

Three properties distinguish an agentic Web3 workflow from a traditional dApp interaction:

1. The agent — not a human — decides which RPC method to call, and when. There is no fixed call sequence.
2. The agent operates autonomously across multiple reasoning steps, often for minutes or hours, without a UI in the loop.
3. The agent reads and writes on-chain state through a node API, which can be raw JSON-RPC, MCP tool calls, or both.

The third property is where most teams underestimate complexity. The LLM is the visible part. The node API layer — how the agent actually talks to the blockchain — is where reliability, latency, and cost live.

The two interfaces between an agent and a blockchain

When a Web3 AI agent needs to interact with a chain, the request flows through one of two interfaces. Sometimes both, in the same reasoning step.

Raw JSON-RPC. The agent (or its tooling) constructs a JSON-RPC payload and sends it directly to a node endpoint. This is how web3.py, ethers.js, and every other Web3 library talk to nodes. It is fast, flexible, and gives the agent full access to every method the node exposes. It is also brittle from an LLM’s perspective: the agent has to know the method name, the parameter order, the encoding rules, and how to interpret the response. Get any of that wrong and the call fails silently or returns junk.

MCP (Model Context Protocol). MCP is an open standard from Anthropic that defines a structured tool interface an LLM can discover and call autonomously. Instead of an agent constructing a raw eth_getBalance payload, it calls an MCP tool like get_balance with named parameters, gets back a typed response, and knows what it received without parsing hex strings. MCP wraps RPC — under the hood, the MCP server still talks to nodes — but it exposes that capability as a tool the LLM can reason about. The Chainstack MCP server is a hosted implementation that gives agents access to node lifecycle operations, documentation search, platform status, and live pricing through a single HTTP endpoint — connection guides are available for Claude and Codex.

The simplest way to think about it: raw JSON-RPC is what the chain speaks. MCP is what the LLM speaks. The agent runtime translates between them.

Interface	Best for	Limitations
Raw JSON-RPC	High-frequency reads, transaction submission, WebSocket subscriptions, methods not exposed by the MCP server	Agent has to know method signatures; failure modes are opaque to the LLM
MCP	Tool discovery, documentation lookup, node deployment, structured queries the LLM can reason about	One layer of indirection; not appropriate for sub-millisecond hot paths

The rest of this article walks through exactly how these two interfaces interleave during one full reasoning cycle. Before that, the anatomy.

Anatomy of a single reasoning step

A single reasoning step inside an agentic Web3 workflow has six stages. They look like this:

1. PROMPT          — the agent receives a goal or sub-goal
2. TOOL SELECTION  — the LLM decides which tool(s) it needs
3. TOOL CALL       — the runtime executes the tool: MCP, raw RPC, or both
4. CHAIN ACCESS    — the node provider returns blockchain state or transaction result
5. INTERPRETATION  — the LLM parses the response and updates its working state
6. DECISION        — the LLM decides whether the step is complete or another tool call is needed

Stages 3 and 4 are where the blockchain node API layer sits. Everything else is LLM mechanics. But stages 3 and 4 determine whether the workflow completes in seconds or stalls at a 429.

Two things compound across reasoning steps. First, a single step rarely uses one RPC call — it uses three to seven, because the LLM tends to verify state before acting (read balance, read allowance, check gas, simulate, then send). Second, a workflow rarely has one step. A stablecoin treasury agent rebalancing positions across three chains can run twenty to fifty reasoning steps in a single execution, each triggering its own bundle of RPC calls. The aggregate load is what breaks shared infrastructure — covered in detail in the Chainstack guide to blockchain RPC for AI agents.

Walkthrough: a stablecoin treasury agent rebalances positions

Concrete example. The scenario is realistic for any fintech or institutional team running stablecoin operations: a treasury holds USDC across Ethereum, Base, and Solana for operational liquidity. When the balance on any chain drops below a threshold — say, $50,000 — the agent moves USDC from the chain with the highest excess to top it up.

The agent’s job: detect the deficit, choose a source chain, simulate the transfer, execute it, and confirm settlement. One full execution cycle, end to end.

Step 1 — The agent gets its goal

The treasury system sends the agent a prompt:

Check USDC balances on Ethereum, Base, and Solana for treasury address 0x7a23…f2c1. If any chain is below $50,000, top it up from the chain with the largest excess. Do not exceed $200,000 in a single transfer.

The LLM parses the goal. It identifies three sub-tasks: read balances, evaluate the deficit, execute the transfer. It needs blockchain access for the first and third.

Step 2 — The agent reads balances across three chains

The LLM decides to use a tool. If the agent is configured with the Chainstack MCP server, it could ask the MCP layer to search docs for the right method, but in this case it already knows: USDC is an ERC-20 on Ethereum and Base, an SPL token on Solana. It needs eth_call to the USDC contract’s balanceOf method on the EVM chains, and getTokenAccountBalance on Solana.

For Ethereum, the agent (via web3.py in its runtime) constructs a JSON-RPC batch:

[
  {"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","data":"0x70a082310000000000000000000000007a23...f2c1"},"latest"],"id":1},
  {"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","data":"0x70a082310000000000000000000000007a23...f2c1"},"latest"],"id":2}
]

That’s two eth_calls — one to USDC on Ethereum, one to USDC on Base — submitted as a JSON-RPC batch over a single HTTP request. Batching cuts three potential round trips down to one and consumes one RPS slot instead of three. (Why batching matters under burst load: see the RPC-for-agents guide.)

On Solana, the agent uses getTokenAccountBalance against the treasury’s USDC token account. Three reads, two HTTP requests, one to each chain provider. The Python that issues these reads looks like this — note that this is the actual code path, not a framework abstraction:

from web3 import Web3
from solana.rpc.api import Client

eth = Web3(Web3.HTTPProvider(CHAINSTACK_ETH_URL))
base = Web3(Web3.HTTPProvider(CHAINSTACK_BASE_URL))
sol = Client(CHAINSTACK_SOL_URL)

USDC_ETH = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
USDC_BASE = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
TREASURY = "0x7a23...f2c1"
TREASURY_SOL_USDC_ACCOUNT = "..."

eth_balance = eth.eth.contract(address=USDC_ETH, abi=ERC20_ABI).functions.balanceOf(TREASURY).call()
base_balance = base.eth.contract(address=USDC_BASE, abi=ERC20_ABI).functions.balanceOf(TREASURY).call()
sol_balance = sol.get_token_account_balance(TREASURY_SOL_USDC_ACCOUNT).value.ui_amount

The runtime returns balances to the LLM as structured data: {"ethereum": 42100, "base": 187500, "solana": 95200}.

Step 3 — The agent evaluates and decides

The LLM now has state. It reasons:

Ethereum is at $42,100 — below the $50,000 threshold by $7,900. Base has $187,500, the largest excess. Source = Base, destination = Ethereum, amount = $10,000 (round up from $7,900 to give buffer, well under the $200,000 cap).

This stage is pure LLM reasoning. No chain access. But it produces the parameters for the next on-chain action.

Step 4 — The agent simulates the transfer before execution

Before sending real funds, the agent simulates. This is the step most non-agentic scripts skip and most production agents include — because the cost of a failed transfer is non-trivial and the cost of a simulation is negligible.

Chainstack nodes expose eth_simulateV1 and full Foundry-forking support for this. The agent constructs a transfer call against the USDC contract on Base, with from = treasury, to = bridge_contract, amount = 10000 * 10**6, and simulates against the current state. If the simulation succeeds and reports the expected balance changes, the agent proceeds. If it fails — wrong allowance, insufficient gas, paused contract — the agent surfaces the error and either retries with adjusted parameters or escalates.

sim_result = base.eth.call({
    "from": TREASURY,
    "to": USDC_BASE,
    "data": transfer_calldata,
})
# sim_result == b'\x00...\x01' means success in ERC-20 transfer simulation

Step 5 — The agent uses MCP to verify it has up-to-date method signatures

This is where MCP earns its keep. Before constructing a cross-chain transfer (USDC on Base going to Ethereum requires bridging through CCTP — Circle’s Cross-Chain Transfer Protocol — not a direct ERC-20 transfer), the agent calls the MCP search_docs tool:

mcp_call: search_docs("USDC cross-chain transfer Base to Ethereum CCTP")

The MCP server returns the relevant documentation pages. The LLM reads them, identifies the correct method signatures and contract addresses for CCTP’s depositForBurn on Base and receiveMessage on Ethereum, and constructs the transaction with verified parameters. This eliminates the most common LLM failure mode: hallucinated method names or stale contract addresses.

Without MCP, the agent has two bad options: rely on the LLM’s training data (which may be outdated), or hardcode the method signature in the agent’s tool definitions (which breaks the moment Circle deploys a new version). MCP lets the agent fetch the canonical truth at runtime.

Step 6 — The agent submits the transaction

Back to raw RPC for the actual write. The agent signs the transaction (using a key held in its own secure environment — never exposed to the LLM context), constructs the eth_sendRawTransaction payload, and submits:

{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": ["0xf86c0a85046c7cfe008252089...signed_tx_hex..."],
  "id": 1
}

The node returns a transaction hash. The agent stores it.

Step 7 — The agent confirms settlement

The transfer is async — CCTP burns USDC on Base, emits an attestation, and Circle’s attestation service signs it. The agent then submits receiveMessage on Ethereum to mint the equivalent USDC. End-to-end, this can take a few minutes.

The agent could poll eth_getTransactionReceipt every few seconds, but that wastes RPS. Better: subscribe to the receipt via WebSocket and let the chain push the confirmation when it lands.

async with websockets.connect(CHAINSTACK_ETH_WS) as ws:
    await ws.send(json.dumps({
        "jsonrpc": "2.0",
        "method": "eth_subscribe",
        "params": ["newHeads"],
        "id": 1
    }))
    # then watch for the destination transaction confirmation

When the destination tx lands and emits the MessageReceived event, the agent has confirmation. Its working state updates: Ethereum balance is now ~$52,100, deficit closed. The workflow ends. The agent logs the cycle and waits for the next polling interval.

What just happened, by the numbers

One execution cycle of this agent generated:

• 3 read calls (balance checks across three chains)
• 2 simulation calls (Base transfer, Ethereum receive)
• 2 documentation lookups via MCP
• 2 write transactions (Base burn, Ethereum mint)
• 1 WebSocket subscription

That’s ~10 distinct interactions with the blockchain layer for a single rebalancing cycle. If this agent runs every five minutes across a 24-hour window, that’s roughly 2,880 chain interactions per day — for one treasury, on stable operating conditions. During market events or fee spikes the load can multiply 3-5x as the agent retries, re-simulates, or escalates.

In Chainstack Request Units, a steady-state day for this treasury runs around 3,000 RUs — most calls are standard full-node reads at 1 RU each, with archive lookups for reconciliation adding 2 RUs each when they occur. A burst day at 5x load comes in under 15,000 RUs. That is the unit economics of one agent. The number to remember when you start adding more.

This is why the choice of node API provider is not incidental for agentic Web3 workflows. It is the substrate.

When to use MCP, when to use raw RPC

The walkthrough above used both interfaces. The choice in each step was deliberate. Here is the underlying logic.

The agent is doing…	Use MCP	Use raw RPC
Looking up which method or contract to use	✅ search_docs	—
Deploying or destroying nodes mid-workflow	✅ node lifecycle tools	—
Reading account balances at high frequency	—	✅ eth_call, batched
Submitting a signed transaction	—	✅ eth_sendRawTransaction
Subscribing to live events	—	✅ WebSocket eth_subscribe
Checking platform or node health programmatically	✅ get_platform_status	—
Decoding an unfamiliar event log	✅ get_doc_page for ABI reference	—
Pricing or quota questions for the agent’s own operations	✅ get_chainstack_pricing	—
Simulating a transaction before send	—	✅ eth_call / eth_simulateV1
Multi-call aggregation across many contracts	—	✅ Multicall3

The pattern: MCP for discovery, governance, and meta-operations. Raw RPC for the hot path of reading and writing chain state.

Agents that try to do everything through MCP add latency to operations that should be sub-100ms. Agents that try to do everything through raw RPC reinvent documentation lookup, error parsing, and node management — usually badly. The right mix uses each for what it is good at.

Multi-step workflow patterns

The treasury walkthrough was a single linear cycle. Real agentic Web3 workflows are rarely linear. Four patterns recur across production agents.

Sequential

One step, then the next. The treasury walkthrough is sequential — balance reads, decision, simulation, send, confirm. Each step waits for the previous one. Easy to reason about, easy to debug, but slow when steps are independent.

Parallel

Multiple sub-agents or sub-tasks execute concurrently against the same node infrastructure. A multi-chain monitor might subscribe to events on six chains in parallel, each running its own reasoning loop. Parallelism multiplies aggregate RPS load — the load profile analysis covers this in detail. The fix is either a Dedicated Node per high-load chain or a single dedicated node with capacity headroom for the parallel fan-out.

Conditional

The agent’s next action depends on what it reads from the chain. The treasury agent only triggers a transfer if a balance threshold is breached. Conditional workflows look light in the average case but produce burst load in the trigger case, when many sequential calls fire in quick succession.

Retry with state preservation

The agent encounters an error mid-workflow — a 429, a failed simulation, a timed-out confirmation. It needs to retry without losing context. This requires the agent runtime to externalize state (typically to a database or message queue) so retries can resume from the last verified state rather than restarting the cycle. Combined with exponential backoff and jitter, this is what separates production agents from demos.

What this means for building production agents

Three things hold across every agentic Web3 workflow worth building.

MCP and raw RPC are not alternatives — they are complementary layers. The agent uses MCP for the operations where the LLM benefits from structure: discovering which method to call, looking up a contract address, checking platform status, deploying or destroying nodes. It uses raw RPC for the operations where structure costs latency: high-frequency reads, signed transaction submission, WebSocket event subscriptions. Trying to force everything through one interface produces either slow agents or fragile ones.

A single reasoning cycle generates enough chain interactions to break shared infrastructure. The treasury walkthrough hit ten in one cycle. A monitoring agent watching six chains in parallel can hit forty across a single decision window. The node API layer has to absorb that without rate-limiting the agent into incoherent retry loops. The full load profile analysis covers exactly how this breaks shared endpoints and what to do about it. This is not optional — it is the practical constraint that determines whether an agentic system reaches production.

The difference between a demo agent and a production agent is state preservation under error. A demo handles the happy path: read, decide, simulate, send, confirm. A production agent handles the day when simulation fails, the confirmation never arrives, the rate limit triggers mid-workflow, or the chain reorgs. Building the agent so it can resume from the last verified state — rather than restart from the original goal — is the work that separates the two.

If the agent is correctly designed and the infrastructure underneath is correctly chosen, the LLM is rarely the limiting factor. The chain interactions are. That is where the engineering attention should go.

The Chainstack pieces

Mapping the walkthrough back to the infrastructure it ran on:

• Global Nodes and Dedicated Nodes — the raw RPC endpoints the agent talks to for reads, writes, and WebSocket subscriptions. Dedicated Nodes eliminate rate-limit contention for production agentic workloads. Global Nodes reduce P99 latency through geo-routing. For agents that need maximum transaction landing rate — high-frequency trading, MEV, time-sensitive arbitrage — Trader Nodes are the right default on Solana.
• MCP server at mcp.chainstack.com/mcp — the structured tool layer for documentation, platform status, pricing, and (with an API key) full node lifecycle. Five tools work without authentication: search_docs, get_doc_page, get_platform_status, get_chainstack_pricing, contact_chainstack. Node deployment tools require a Chainstack API key.
• Archive Data and Debug & Trace APIs — for agents that need historical state reconstruction, transaction-level execution traces, or audit reconciliation. Costs 2 RUs per call versus 1 RU for standard full-node calls.
• Simulation support — eth_simulateV1, eth_call, Foundry forking, Solana simulateTransaction. The agent in the walkthrough used these to verify transfers before execution.
• WebSocket subscriptions and gRPC streaming — eth_subscribe and chain-specific equivalents on EVMs; Yellowstone gRPC for Solana for structured real-time data streaming. Push-based event delivery instead of polling. Reduces RPS consumption and latency for event-driven agents.
• 70+ supported chains (as of 2026) — Ethereum, Solana, Base, Polygon, Arbitrum, BNB Smart Chain, Hyperliquid, Monad, MegaETH, Tempo, Tron, and others. A multi-chain agent gets a single provider rather than five.

To connect an agent to Chainstack: register an MCP endpoint and deploy your first node in under a minute. No credit card required for the Developer plan.

FAQ

Related reading

• Blockchain RPC for AI agents: infrastructure guide (2026)
• AI-ready infrastructure on Chainstack
• Chainstack MCP server
• How to connect Chainstack MCP server to Claude
• How to connect Chainstack MCP server to Codex
• Building a Web3 AI trading agent from scratch
• Chainstack MCP server documentation
• Mastering Web3 LLMs and AI use