Etherscan Launches AI API Suite for Real-Time Data Access Across 60+ Chains

Etherscan has shipped a new "Build with AI" tool suite that exposes on-chain data from over 60 EVM-compatible chains through API access and Model Context Protocol integration, according to a ChainCatcher report distributed by KuCoin. The release targets developers building AI agents that need authenticated, real-time reads of transactions and contract state. For protocol and dApp engineers, this shifts the integration cost floor for any agentic workflow that currently scrapes block explorers or runs its own indexer.

Three Interfaces, One Data Layer

The suite ships three access points: an MCP server for mainstream coding agents, a CLI that outputs structured JSON, table, or CSV directly in the terminal with an interactive interface, and a Skills module packaging pre-built capabilities like contract review, transaction debugging, and workflow orchestration. The CLI path is the one most worth testing first — it removes the JSON-RPC and ABI-decoding boilerplate that usually sits between a terminal and an archive node, letting you sanity-check queries before wiring them into a script. Conversely, the Skills layer is the more interesting architectural bet: it abstracts multi-step debugging into a callable agent task, which is exactly the pattern senior engineers either embrace or distrust depending on how much observability they retain underneath the abstraction. The MCP integration explicitly names Claude and Codex as supported clients, meaning the natural-language front door is already wired for the agents most teams are experimenting with today.

What to Validate Before Wiring It In

Two things worth pressure-testing before any production traffic hits these interfaces. First, latency and freshness — the announcement promises real-time access, but real-time in the Etherscan ecosystem has historically meant polled node reads with a measurable lag, not push-based streams. Benchmark a hot-path query on a congested chain (token transfers on a busy L2 is the standard stress test) and compare end-to-end latency against your current RPC provider or indexer. Second, confirm the auth model and the data boundary: does the MCP integration expose read-only public state, or does an agent's session inherit any privileged context? That distinction decides whether the suite stays in monitoring land or becomes a serious surface for automated execution, and the documentation, not the marketing, is where the answer lives.

For teams already maintaining their own indexer, treat this as a convenience layer that shortens prototyping cycles, not a replacement for your data pipeline. For teams exploring agent-driven analytics or on-chain automation for the first time, it lowers the barrier enough that a weekend proof-of-concept becomes realistic. Either way, the practical move is the same: spin up the CLI, run a few representative queries against your slowest path, and only then decide whether the throughput and finality profile fits your trade-off matrix.