Provide AI agents and automation tools with contextual access to blockchain data including balance…
The ai.smithery/blockscout-mcp-server is a Model Context Protocol (MCP) server that provides AI agents and automation tools contextual access to blockchain data, including balance. It wraps Blockscout APIs and exposes blockchain data through MCP context-aware APIs for consumption, querying, and analysis.
🛠️ Key Features
Wraps Blockscout APIs for blockchain data access
Exposes blockchain data, including balance
Uses the MCP open protocol for context-aware APIs
🚀 Use Cases
Enabling AI agents to query and analyze blockchain data
Supporting IDE and automation tools that consume structured context via MCP
⚡ Developer Benefits
Standardized MCP interface for structured data consumption
Direct use of Blockscout-backed blockchain information (e.g., balances)
⚠️ Limitations
Available details do not specify all supported fields or a complete API surface (only “balance” is mentioned)
The Model Context Protocol (MCP) is an open protocol designed to allow AI agents, IDEs, and automation tools to consume, query, and analyze structured data through context-aware APIs.
This server wraps Blockscout APIs and exposes blockchain data—balances, tokens, NFTs, contract metadata—via MCP so that AI agents and tools (like Claude, Cursor, or IDEs) can access and analyze it contextually.
Key Features:
Contextual blockchain data access for AI tools
Multi-chain support via Blockscout PRO API configuration with Chainscout metadata enrichment
Versioned REST API: Provides a standard, web-friendly interface to all MCP tools. See API.md for full documentation.
Custom instructions for MCP host to use the server
Intelligent context optimization to conserve LLM tokens while preserving data accessibility
Smart response slicing with configurable page sizes to prevent context overflow
Opaque cursor pagination using Base64URL-encoded strings instead of complex parameters
Automatic truncation of large data fields with clear indicators and access guidance
Standardized ToolResponse model with structured JSON responses and follow-up instructions
Enhanced observability with MCP progress notifications and periodic updates for long-running operations
Enhanced Analysis with Agent Skills
For more powerful and efficient blockchain analysis, install the Blockscout Analysis skill from the agent-skills repository. This skill provides AI agents with structured guidance for execution strategies, response handling, security best practices, and workflow orchestration.
Learn more: See the agent-skills README for full capabilities and installation instructions.
Configuring MCP Clients
Blockscout PRO API Key
Configuring the Blockscout MCP server with an AI agent requires a Blockscout PRO API key. Most of the data tools route their requests through the authenticated Blockscout PRO API gateway, so without a valid key those tools fail fast before making any upstream request.
To obtain a key, register on the Blockscout Developer Portal (the free tier does not require a credit card) and generate an API key; keys are prefixed proapi_. Then supply it when configuring your client, as shown in the sections below.
Claude Setup (Web, Desktop, Cowork) - Recommended
The easiest way to use the Blockscout MCP server with Claude is the official hosted server: a native, managed installation experience with automatic updates and nothing to run yourself. Add it as a Custom Connector with your own PRO API key. Claude sends the key on every request in an x-api-key header, which the server accepts as an alias for its Blockscout-MCP-Pro-Api-Key header.
Open Claude and go to Customize > Connectors. On Team and Enterprise plans an organization Owner does this under Organization settings > Connectors.
Click Add custom connector. Set the name to Blockscout and the URL to https://mcp.blockscout.com/mcp, then continue.
Leave Authentication as None (Claude detects it). A warning that the connector has no credentials is expected: the key is supplied in the next step.
Open Request headers, select x-api-key from the list, and paste your PRO API key as the value. Pick exactly this name; the server does not read the other similar-looking names in the list.
Click Add.
Note: The Request headers section is in beta and is not yet available to every organization. If your dialog does not show it, use the Connectors Directory below.
Note: On Team and Enterprise plans the key is entered once by the Owner and shared by the whole organization. Authentication settings cannot be edited after a connector is added: to change the key, remove the connector and add it again.
Using Claude Connectors Directory
If the Custom Connector dialog has no Request headers section, install the Blockscout connector from the official Anthropic Connectors Directory. It connects to the same hosted server but uses a shared access key.
After running this command, Blockscout will be available as an MCP server in Claude Code, allowing you to access and analyze blockchain data directly from your coding environment.
Edit ~/.codex/config.toml to add the PRO API key header and enable the streamable-HTTP MCP client (required for remote MCP servers to connect). The resulting configuration should look like this:
Add the server to your Cursor MCP configuration — either the project-level .cursor/mcp.json or the global ~/.cursor/mcp.json — supplying your PRO API key via the Blockscout-MCP-Pro-Api-Key header:
Refer to TESTING.md for comprehensive instructions on running both unit and integration tests.
Tool Descriptions
__unlock_blockchain_analysis__() - Initializes a Blockscout MCP session: returns server reference data, the blockscout-analysis skill pointer, and the URI resolution rule. Call it once per session, before any other tool.
get_chains_list(query=None) - Returns a list of supported chains, with optional filtering by name, chain ID, native currency, or ecosystem.
get_address_by_ens_name(name) - Converts an ENS domain name to its corresponding Ethereum address.
lookup_token_by_symbol(chain_id, symbol) - Searches for token addresses by symbol or name, returning multiple potential matches.
get_contract_abi(chain_id, address) - Retrieves the ABI (Application Binary Interface) for a smart contract.
inspect_contract_code(chain_id, address, file_name=None) - Allows getting the source files of verified contracts.
get_address_info(chain_id, address) - Gets comprehensive information about an address including balance, ENS association, contract status, token details, and public tags.
get_tokens_by_address(chain_id, address, cursor=None) - Returns detailed ERC20 token holdings for an address with enriched metadata and market data.
get_block_number(chain_id, [datetime]) - Retrieves the block number and timestamp for a specific date/time or the latest block.
get_transactions_by_address(chain_id, address, age_from, age_to, methods, cursor=None) - Gets transactions for an address within a specific time range with optional method filtering.
get_token_transfers_by_address(chain_id, address, age_from, age_to, token, cursor=None) - Returns ERC-20 token transfers for an address within a specific time range.
nft_tokens_by_address(chain_id, address, cursor=None) - Retrieves NFT tokens owned by an address, grouped by collection.
get_block_info(chain_id, number_or_hash, include_transactions=False) - Returns block information including timestamp, gas used, burnt fees, and transaction count. Can optionally include a list of transaction hashes.
get_transaction_info(chain_id, hash, include_raw_input=False) - Gets comprehensive transaction information with decoded input parameters and detailed token transfers.
read_contract(chain_id, address, abi, function_name, args='[]', block='latest') - Executes a read-only smart contract function and returns its result. The abi argument is a JSON object describing the specific function's signature.
direct_api_call(chain_id, endpoint_path, query_params=None, cursor=None, method='GET', json_body=None) - Calls a raw Blockscout API endpoint for advanced or chain-specific data. Supports GET (default) and POST requests with JSON body.
Example Prompts for AI Agents
plaintext
Is any approval set for OP token on Optimism chain by `zeaver.eth`?
plaintext
Calculate the total gas fees paid on Ethereum by address `0xcafe...cafe` in May 2025.
plaintext
Which 10 most recent logs were emitted by `0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7`
before `Nov 08 2024 04:21:35 AM (-06:00 UTC)`?
plaintext
Tell me more about the transaction `0xf8a55721f7e2dcf85690aaf81519f7bc820bc58a878fa5f81b12aef5ccda0efb`
on Redstone rollup.
plaintext
Is there any blacklisting functionality of USDT token on Arbitrum One?
plaintext
What is the latest block on Gnosis Chain and who is the block minter?
Were any funds moved from this minter recently?
plaintext
When the most recent reward distribution of Kinto token was made to the wallet
`0x7D467D99028199D99B1c91850C4dea0c82aDDF52` in Kinto chain?
plaintext
Which methods of `0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6` on the Ethereum
mainnet could emit `SequencerBatchDelivered`?
plaintext
What is the most recent executed cross-chain message sent from the Arbitrum Sepolia
rollup to the base layer?
Development & Deployment
Local Installation
Clone the repository and install dependencies:
bash
git clone https://github.com/blockscout/mcp-server.git
cd mcp-server
uv pip install -e . # or `pip install -e .`
To customize the leading part of the User-Agent header used for RPC requests,
set the BLOCKSCOUT_MCP_USER_AGENT environment variable (defaults to
"Blockscout MCP"). The server version is appended automatically.
Providing the PRO API Key to the Server
When you run the server yourself, provide the Blockscout PRO API key through the BLOCKSCOUT_PRO_API_KEY environment variable — exported in your shell or placed in a gitignored .env file in the project root. This enables all data access, public-tag enrichment, and contract reads. Never commit the key or embed it in a client-shipped binary; when running via Docker, pass it at runtime (e.g. -e BLOCKSCOUT_PRO_API_KEY=...) rather than baking it into the image.
Client-supplied keys (HTTP transports). When the server runs in HTTP mode, a client can supply its own PRO API key in a request header — by default Blockscout-MCP-Pro-Api-Key, configurable via BLOCKSCOUT_PRO_API_KEY_HEADER (set it to an empty string to disable client-supplied keys entirely). The server also reads the key from an x-api-key header, for clients whose header names are restricted to a fixed list (for example Claude Custom Connectors). The configured header wins when both are present; x-api-key is consulted only when the configured header is missing or blank, and disabling client-supplied keys disables it too. This works the same way for both HTTP transports — MCP-over-HTTP tool calls and the REST API. A client-supplied key takes precedence over BLOCKSCOUT_PRO_API_KEY for that request; if the client sends no key, the server falls back to its own configured key; if neither is present, the request fails with the not-configured error. A client key that is present but malformed fails any request that needs the PRO API with no fallback (the server never silently uses its own key in place of a bad client key); tools that don't use the PRO API are unaffected. This makes it possible to run a shared HTTP server where each client authenticates with its own key.
Low-credit warning. Access to the PRO API is metered in credits. When the remaining balance reported by the API drops below a configurable threshold, every data tool appends an advisory note to its response, prompting operators to top up so PRO API access stays ready for continued high-volume usage. The threshold is set via BLOCKSCOUT_PRO_API_LOW_CREDITS_THRESHOLD (default 5000 credits; set to 0 to disable the note). The note fires for any balance below the threshold, including zero and negative balances.
PRO API key requirement notice.BLOCKSCOUT_PRO_API_KEY_REQUIRED_NOTICE holds an operator-configured notice that the server appends as the last entry of the notes field of tool responses whose requests did not carry the client's own (well-formed) PRO API key. It exists to announce the official public server's migration to mandatory client-supplied keys, so only the official deployment is expected to set it. When the variable is unset or empty (the default), the feature is completely off. Community and self-hosted operators should leave it empty — in particular in stdio mode, where you configure BLOCKSCOUT_PRO_API_KEY yourself and no request header can carry a client key, the notice would only repeat a migration message that does not apply to your deployment.
Running the Server
The server runs in stdio mode by default:
bash
python -m blockscout_mcp_server
HTTP Mode (MCP only):
To run the server in HTTP Streamable mode (stateless, SSE responses by default):
bash
python -m blockscout_mcp_server --http
You can also specify the host and port for the HTTP server:
Note: This disables Server-Sent Events (SSE) and progress notifications. Only use this for local testing and debugging.
Tunneling with Ngrok (Development Mode):
The Python MCP SDK enforces DNS rebinding protection, which blocks requests from ngrok tunnels by default. To enable
tunneling for development and testing:
Start an ngrok tunnel to your local server:
bash
ngrok http 8000
Configure the allowed host and origin using your ngrok URL:
Note: These settings are primarily for development use. When these variables are not set, DNS rebinding protection
is automatically determined by the server's bind host: enabled for localhost, disabled for non-localhost (e.g.,
0.0.0.0). If your Host header includes a non-standard port, use the :* wildcard suffix (e.g.,
"example.com:*") or specify the exact host:port value.
Session metering limits how many tool calls a caller without a client-supplied PRO API key may make per session identifier issued by __unlock_blockchain_analysis__. It is off by default. Enabling it means setting a signing secret (at least 32 bytes — generate it, don't invent it), and it requires HTTP mode and a server-side PRO API key (metered calls are served upstream on it), plus a persistent volume for the session database. Generate the secret once and store it durably (a secret manager, or persistent environment configuration); every restart and redeploy must pass the same stored value:
bash
# Once, not per start: generate the secret and keep it.
BLOCKSCOUT_SESSION_SECRET="$(python -c 'import secrets; print(secrets.token_urlsafe(32))')"
docker run --rm -p 8000:8000 \
-v blockscout-mcp-sessions:/data \
-e BLOCKSCOUT_SESSION_SECRET="$BLOCKSCOUT_SESSION_SECRET" \
-e BLOCKSCOUT_SESSION_DB_PATH=/data/sessions.db \
-e BLOCKSCOUT_PRO_API_KEY=proapi_your_key_here \
ghcr.io/blockscout/mcp-server:latest python -m blockscout_mcp_server --http --http-host 0.0.0.0
Most deployments do not need any of this: leave BLOCKSCOUT_SESSION_SECRET unset (the default) and no volume is required. Losing the volume or rotating the secret invalidates live session identifiers by design; the exposure is bounded by the configured TTL. Re-generating the secret inline on every docker run is the accidental form of that rotation — it wipes all live identifiers on each restart even though the database volume survived, so never embed the generation command in the start command. Restoring an older copy of the database revives the budgets it recorded — after a historical restore, rotate the secret unless that is intended. Optional knobs: BLOCKSCOUT_SESSION_MCP_MAX_CALLS and BLOCKSCOUT_SESSION_REST_MAX_CALLS (per-surface call ceilings over one shared per-identifier counter; both default 5; 0 closes metered access on that surface while leaving identifier issuance and get_chains_list navigation open), BLOCKSCOUT_SESSION_TTL_SECONDS (default 900), and BLOCKSCOUT_SESSION_SWEEP_INTERVAL_SECONDS (how often expired session rows are cleaned up; default: once per TTL).
Stdio Mode: The default stdio mode is designed for use with MCP hosts/clients (like Claude Desktop, Cursor) and doesn't make sense to run directly with Docker without an MCP client managing the communication.
Testing with Claude Desktop
Use MCP bundle to test the server with Claude Desktop.
Double-click to open the blockscout-mcp-dev.mcpb file to automatically install the bundle.
Configure the Blockscout MCP Server URL when prompted (default: http://127.0.0.1:8000/mcp)
Privacy and Anonymous Telemetry
To help us improve the Blockscout MCP Server, community-run instances of the server collect anonymous usage data by default. This helps us understand which tools are most popular and guides our development efforts.
What we collect:
The name of the tool being called (e.g., get_block_number).
The parameters provided to the tool (the session_id parameter is masked to a placeholder before transmission).
The version of the Blockscout MCP Server being used.
A one-way, non-reversible hash (SHA-256) of the PRO API key available to authorize the request, when one is present. This is a derived fingerprint only — the key itself is never transmitted and cannot be recovered from the hash.
What we DO NOT collect:
We do not collect any personal data, IP addresses (the central server uses the sender's IP for geolocation via Mixpanel and then discards it), or secrets and private keys themselves. The PRO API key in particular is never transmitted — only its one-way, non-reversible fingerprint described above, from which the key cannot be recovered.
How to Opt-Out
You can disable this feature at any time by setting the following environment variable: