So Your AI Coding Assistant Can't See the Blockchain?

There's a weird gap in how AI coding assistants work today. They can write a Solidity contract from a napkin spec. They can scaffold a frontend that talks to that contract. They'll catch reentrancy bugs you missed at 2am. But if you ask one a genuinely simple question - "hey, did my deploy actually go through?" - it can't tell you. It doesn't know. It has no way to look.

Your AI assistant can write code that reads the blockchain, but it can't read the blockchain itself. It's like having a very talented translator who's never allowed to listen to the conversation.

This post is about why that gap exists, what MCP is and how it closes that gap, and some fun things that become possible once your AI can actually see what's happening on-chain.

Why AI agents are blind to on-chain data

It helps to understand why this limitation exists in the first place.

Large language models work with text. They're trained on text, they reason in text, they produce text. When you ask Claude or Copilot to write a smart contract, it's doing something it's built for - generating text that happens to be code.

But blockchain state isn't text. It's a live, constantly changing database distributed across thousands of nodes. To check a balance, you need to make an RPC call to an actual node. To decode a failed transaction, you need to fetch the receipt, extract the revert data, and run it through an ABI decoder. These are runtime operations, not text generation tasks.

Without a way to make those calls, the model can only work with what's in the conversation: the code you pasted in, the error message you copied, whatever context you manually provided. It's working with a snapshot you gave it, not with reality.

MCP: giving AI tools hands (and eyes)

This is where the Model Context Protocol comes in. MCP is an open standard - think of it as a plugin system for AI assistants. It lets your AI client (Claude Desktop, Cursor, VS Code, Claude Code, Windsurf, Gemini CLI) connect to external servers that expose tools the model can call during a conversation.

The key insight is that the model doesn't need to know how to make an RPC call. It just needs to know that a tool called eth_get_balance exists, what parameters it takes, and what it returns. The MCP server handles the actual blockchain interaction. The model handles the reasoning.

This is a general pattern - MCP servers exist for databases, APIs, file systems, all sorts of things. But for blockchain developers specifically, it solves a problem that's been surprisingly annoying: your AI assistant can finally look things up instead of asking you to look things up for it.

What this looks like in practice (with real addresses)

We built Boar's Blockchain MCP , a remote MCP server with 50 read-only tools covering Bitcoin, Ethereum, and Mezo. No install, no API key, no account. It runs on Cloudflare's edge, uses Streamable HTTP transport with SSE fallback, and every request is stateless.

But enough about the plumbing. Let's talk about what you can actually do with it, because that's where it gets interesting.

Settle a mass between friends

Your coworker insists Vitalik has moved most of his ETH out of his main wallet. You're not so sure. Instead of alt-tabbing to Etherscan:

"Resolve vitalik.eth and tell me the current ETH balance. Also, has the address received any transactions in the last 10 blocks?"

The agent resolves the ENS name, fetches the balance, and checks recent activity. Argument settled in 15 seconds without leaving your editor. (Spoiler: he still has quite a bit.)

The "is this contract what I think it is?" moment

You're reading through someone's codebase and they're importing a contract at 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48. No comment explaining what it is. Classic.

"What is the contract at 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 on Ethereum? Fetch its ABI and give me a summary of what it can do."

The agent verifies it's a contract (not an EOA), pulls the verified ABI from Sourcify, and tells you it's the USDC proxy - listing transfer, approve, balanceOf, mint, burn, the Transfer event, all of it. You can then ask follow-up questions: "what's the total supply?" and it'll call eth_call to read directly from the contract.

This beats the workflow of: open browser → navigate to Etherscan → paste address → click "Contract" tab → click "Read Contract" → scroll through the list.

Archaeology on the Bitcoin genesis block

This one's just fun:

"Look up the balance and UTXOs for Satoshi's address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. How many people have sent BTC to it, and what's the total?"

The agent calls btc_get_balance and btc_get_utxos and returns years worth of accumulated donations from people sending small amounts to the genesis address. It's a great way to test that your Bitcoin tooling works, and honestly it's just a fun rabbit hole to go down with an AI that can actually read the data.

The 3am "why did this revert?" debugging session

Your transaction failed. The receipt says status: 0x0. Very helpful, Ethereum.

"Transaction 0x596030fc0f8e2ccf193ce5f2b661446d48645da5621d02938621e2c1b6b93e2a failed on Ethereum. Fetch the receipt, decode the revert reason, and explain what went wrong in plain English."

The agent pulls the receipt, extracts the revert data, decodes it, and tells you: this was a Uniswap V3 swap that failed because the transaction deadline had passed. In plain English. No hex decoding, no ABI lookup, no opening five different tabs.

This is the kind of thing that takes 30 seconds with the MCP and 10 minutes without it - and at 3am, that difference matters a lot.

Batch-reading contract state without writing a script

You need to check 5 different values from a contract - maybe prices from an oracle, balances from a vault, or parameters from a governance contract.

"Use Multicall3 to batch-read the following from contract 0x...: totalSupply, paused, owner, decimals, and symbol."

One call, five results. No for-loop, no script, no waiting for sequential RPC responses. The agent batches everything through eth_multicall and gives you a clean summary.

The setup - it's embarrassingly simple

All of this works once you add a URL to a config file. Here's the quick version for the most popular clients.

Claude Desktop - add to claude_desktop_config.json:

{
  "mcpServers": {
    "boar-blockchain-mcp-basic": {
      "type": "streamable-http",
      "url": "https://mcp.boar.network/basic"
    },
    "boar-blockchain-mcp-advanced": {
      "type": "streamable-http",
      "url": "https://mcp.boar.network/advanced"
    }
  }
}

Claude Code - run in terminal:

claude mcp add boar-blockchain-mcp-basic --transport http --scope project https://mcp.boar.network/basic
claude mcp add boar-blockchain-mcp-advanced --transport http --scope project https://mcp.boar.network/advanced

Configuration for Cursor, VS Code, Windsurf, Gemini and others is here.

That's the /basic endpoint with 37 tools - balances, transactions, blocks, logs, gas, ENS, ABIs. It covers most of what you'll need.

When you want contract calls, revert decoding, calldata encoding, or Multicall3, add the /advanced endpoint as a second server (13 tools, completely separate set, no overlap).

One thing worth knowing: each endpoint adds its tool descriptions to your AI's context window. If you're working on something where context space is tight, start with just /basic and add /advanced only when you need it.

Why "read-only" is a feature, not a limitation

Every tool is strictly read-only. No transaction signing, no private key access, no state modification.

A read-only surface area means the security model is simple. There's no risk of your AI agent accidentally sending a transaction, approving a token spend, or interacting with a malicious contract in a way that costs you money. It can look at everything, touch nothing. For a tool that's designed to run inside your AI assistant - where prompts can be ambiguous and the model is making autonomous tool calls - that's exactly the trust model you want.

Things people don't immediately think of

Beyond the obvious "look up a balance" use case, a few patterns have surprised us.

Onboarding new team members gets easier. Someone who's new to blockchain development can ask "what tokens does this address hold?" or "what happened in this transaction?" in plain English. They don't need to learn cast, pick the right block explorer, or parse JSON-RPC responses. The AI translates between "human question" and "blockchain query" automatically.

Exploring unfamiliar chains becomes frictionless. The interface is the same whether you're looking at Bitcoin UTXOs, Ethereum contract state, or Mezo token balances. You don't need to find the right explorer, learn a new CLI, or figure out which RPC methods a chain supports. You just ask.

And if you're building AI agents that need on-chain awareness - monitoring bots, analytics pipelines, research tools - the MCP gives you a clean interface without writing custom RPC code for each chain.

The repo, the docs, and how to break things

The whole thing is MIT-licensed and lives on GitHub. The repo includes full tool references for the basic and advanced endpoints, setup guides for every supported client, and a prompt cookbook with six detailed workflows you can copy-paste right now.

We're adding more chains and more tools based on what people actually use. If you try it and something doesn't work the way you'd expect, or you want support for a chain we don't cover yet, open an issue. The best features we've shipped so far came from exactly that kind of feedback.

So - what's the first thing you'd ask your AI to look up on-chain? We've been having fun with increasingly weird prompts internally, and we're curious what people come up with.