Nuthatch

What nuthatch MCP server does

The nuthatch MCP server gives MCP clients access to indexed EVM contract history stored in a local nest. A nest contains the contract ABI, its configuration, and the data collected by the indexer. The resulting database exposes contract events as per-event tables, which can be queried with SQL.

Nuthatch is designed for cases where reading contract history would otherwise require a subgraph, custom handler code, or a separately managed database. It generates the schema and decoders from the ABI, so the user does not need to author indexing logic for the contract's events. The data remains on the user's machine, and the project does not run a hosted nest service.

How it works

Run nuthatch init with a contract address to create a nest. The command resolves the ABI through Sourcify and then Etherscan, generates the schema and decoders, and scaffolds the local project. Chain selection can be automatic for the built-in networks, or supplied explicitly for another EVM-compatible chain.

nuthatch dev reads the chain through JSON-RPC, backfills the selected history, and continues following new blocks. A short backfill can make recent rows available quickly; omitting the backfill starts from the contract's deployment block, which may require a much longer sync. The bundled public endpoints are intended for evaluation, while a paid endpoint or self-hosted node is recommended for long-running use.

The nuthatch MCP server is built into the binary and lets Claude or another MCP client query the local indexed data. SQL can also be issued directly with nuthatch sql, providing the same database-oriented way to inspect event history.

Setup and configuration

Install the release script on macOS Apple Silicon or Linux x86_64 and aarch64, then ensure ~/.local/bin is on PATH. Linux releases from version 4.1.0 require glibc 2.35 or newer. Intel Macs and platforms without a published binary require a source build with Rust 1.95.0. Release container images are also published through the project's GitHub Container Registry.

A basic workflow is:

• Initialize a contract with nuthatch init ADDRESS, optionally adding an alias.
• Start indexing with nuthatch dev, using --backfill for a limited recent range.
• Query event tables with nuthatch sql or through an MCP client.

Nine networks have built-in configuration: Ethereum, Arbitrum One, Base, BSC, Polygon, Gnosis, Optimism, Monad, and Robinhood Chain. Other EVM chains can be named and paired with an RPC endpoint. The --rpc option also lets users replace the bundled endpoints for built-in networks.

Tools and capabilities

The nuthatch MCP server supports agent access to the locally indexed contract database. Its core capability is SQL querying over event tables, including both sealed history and the current live tip. The command-line interface also provides initialization, development indexing, and direct SQL execution.

Nuthatch uses one Rust binary and embedded storage, without requiring Postgres, Docker, IPFS, or a subgraph. Single-chain tip-following is constrained to at most 2 GB of RAM according to the project. No telemetry is enabled by default, and an account or mandatory API token is not required.

Limitations and notes

Nuthatch still depends on an EVM JSON-RPC endpoint. Public endpoints are suitable for trying the workflow but may not be appropriate for sustained indexing. Large historical backfills can take substantial time, especially when starting at a contract's deployment block.

The published Linux binary has a glibc floor, and no Intel Mac binary is provided. Unlisted chains may require additional attention to finality behavior; the project notes that a chain whose finalized tag is close to the tip may need a depth-based policy instead. Nuthatch indexes contract history locally rather than serving a shared hosted copy, so each deployment manages its own nest and data.