Which integrations are available for this server?

Provides blockchain data for Ethereum, including wallet balance checks, transaction details, latest blocks, and current gas price via GetBlock.io API. Provides blockchain data for Solana, including account information, wallet balance, transaction details, and latest blocks via GetBlock.io API.

How do I use MCP GetBlock Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP GetBlock Server what's the current gas price on Ethereum?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP GetBlock Server

Official

by GetBlock-io

Overview Schema Related Servers Score Discussions

JavaScript

Remote

MCP GetBlock Server

Model Context Protocol (MCP) server for interacting with GetBlock.io API.

Features

Blockchain data requests from various networks (ETH, Solana)
Real-time blockchain statistics
Wallet balance checking
Transaction status monitoring
Getting Solana account information
Getting current gas price in Ethereum
JSON-RPC interface to blockchain nodes
Environment-based configuration for API tokens

Related MCP server: MCP Etherscan Server

Installation

Option 1: Standard Node.js Installation

Install dependencies:

npm install

Compile TypeScript:

npm run build

Create a .env file with access tokens for different blockchains (optional):

# Access tokens for different blockchains
ETH_ACCESS_TOKEN=your_eth_access_token_here
SOLANA_ACCESS_TOKEN=your_solana_access_token_here

Start the server:

npm start

Option 2: Using Docker

Build the Docker image:

docker build -t mcp/getblock:latest .

Run the container with environment variables:

docker run -i --rm \
  -e ETH_ACCESS_TOKEN=your_eth_access_token_here \
  -e SOLANA_ACCESS_TOKEN=your_solana_access_token_here \
  mcp/getblock:latest

Development

For development, you can use the command:

npm run dev

This command will compile TypeScript and start the server.

Use with Claude Desktop, Cursor, or other IDE

Option 1: Direct Launch via Node.js

Configure Claude Desktop to use this server by editing claude_desktop_config.json:

{
    "mcpServers": {
        "getblock": {
            "command": "npm",
            "args": [
                "start",
                "--prefix",
                "/ABSOLUTE/PATH/TO/mcp-getblock"
            ],
            "env": {
                "ETH_ACCESS_TOKEN": "your_eth_access_token_here",
                "SOLANA_ACCESS_TOKEN": "your_solana_access_token_here"
            }
        }
    }
}

Option 2: Launch via Docker

Configure Claude Desktop to use the Docker container:

{
    "mcpServers": {
        "getblock": {
            "command": "docker",
            "args": [
                "run",
                "-i",
                "--rm",
                "-e",
                "ETH_ACCESS_TOKEN",
                "-e",
                "SOLANA_ACCESS_TOKEN",
                "mcp/getblock:latest"
            ],
            "env": {
                "ETH_ACCESS_TOKEN": "your_eth_access_token_here",
                "SOLANA_ACCESS_TOKEN": "your_solana_access_token_here"
            }
        }
    }
}

Restart Claude Desktop
You should see the available tools in the toolbar

Available Tools

get-chain-info - get general information about a blockchain network (ETH, Solana)
get-wallet-balance - check wallet balance on the blockchain
get-transaction - get details about a specific transaction
get-latest-blocks - get information about the latest blocks
get-solana-account - get information about a Solana account
get-eth-gas-price - get current gas price in the Ethereum network

Detailed Tool Descriptions

get-chain-info

{
  "name": "get-chain-info",
  "description": "Get general information about a blockchain network",
  "inputSchema": {
    "properties": {
      "chain": {
        "type": "string",
        "description": "Blockchain network (e.g., eth, solana)",
        "default": "eth"
      }
    }
  }
}

get-wallet-balance

{
  "name": "get-wallet-balance",
  "description": "Get the balance of a wallet address on a blockchain",
  "inputSchema": {
    "properties": {
      "address": {
        "type": "string",
        "description": "The wallet address to check"
      },
      "chain": {
        "type": "string",
        "description": "Blockchain network (e.g., eth, solana)",
        "default": "eth"
      }
    },
    "required": ["address"]
  }
}

get-transaction

{
  "name": "get-transaction",
  "description": "Get details of a specific transaction",
  "inputSchema": {
    "properties": {
      "txid": {
        "type": "string",
        "description": "Transaction ID/hash"
      },
      "chain": {
        "type": "string",
        "description": "Blockchain network (e.g., eth, solana)",
        "default": "eth"
      }
    },
    "required": ["txid"]
  }
}

Access Token Priority Order

Access tokens are used in the following priority order:

Tokens passed through environment variables (env in claude_desktop_config.json)
Tokens from the .env file
Default values (if not specified in items 1 and 2)

Architecture & Technology Stack

Language: TypeScript (compiled to JavaScript)
Runtime: Node.js
Communication Protocol: Model Context Protocol (MCP)
API Integration: GetBlock.io JSON-RPC API
Authentication: Token-based API authentication
Transport Layer: Standard I/O (stdio) for communication with Claude Desktop
Dependencies:
- @modelcontextprotocol/sdk: For MCP implementation
- axios: HTTP client for API requests
- dotenv: Environment variable management

Supported Networks

As of June 2025, this MCP server supports the following blockchain networks:

Primary Networks

Ethereum (ETH) - Full support for balance, transaction, block, and gas price queries
Solana (SOL) - Support for balance, account info, transaction, and block queries

Future Expansions

Support for additional networks from GetBlock.io's infrastructure (which includes over 75+ blockchain networks [1]) can be implemented by extending the current codebase.

Examples of Usage

Checking ETH Balance

You can ask Claude to check the balance of an Ethereum wallet by using the get-wallet-balance tool:

What is the balance of this Ethereum wallet: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045?

Viewing Transaction Details

To get information about a specific transaction:

Can you show me the details of this Ethereum transaction: 0x0ac94a788a79e3eaa72a33f1da97b79728b570054fe156a7f60e06f5791aaf36?

Getting Current Gas Price

To check the current gas prices on Ethereum:

What are the current gas prices on Ethereum?

Implementation Details

Server Architecture

The server follows a simple architecture:

Initialization: The server initializes using the MCP SDK and configures the supported tools
Tool Registration: Each blockchain operation is registered as a separate tool with its own input schema
Request Handling: Incoming requests are processed by the main handler which:
- Extracts the tool name and arguments
- Validates input parameters
- Constructs the appropriate JSON-RPC call to GetBlock API
- Processes the response and returns formatted results
Authentication: API tokens are managed with a priority system using environment variables

Code Structure

Tool Definitions: Each blockchain operation is defined as a separate tool with metadata
Request Handler: Main logic for processing tool invocations
API Integration: Helper functions for constructing and sending requests to GetBlock
Response Processing: Formatting and conversion of blockchain data (e.g., wei to ether)

Troubleshooting

API Connection Issues

If you encounter connection issues to the GetBlock API:

Verify that your access tokens are correctly set in environment variables or .env file
Check if the GetBlock service is operational
Ensure your network can reach the GetBlock API servers

Invalid Response Format

If you receive error messages about invalid response format:

Verify that the blockchain and method you're using are supported by GetBlock
Check if your access token has sufficient permissions
Ensure the parameters are correctly formatted for the specific blockchain

Available Tools

6 tools

get-chain-infoC

Get general information about a blockchain network

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No	Blockchain network (e.g., eth, solana)	eth

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It only states output purpose but does not mention that it is read-only, what specific information is returned, or any constraints such as rate limits or authorization needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. However, it is not front-loaded with critical information that helps the agent decide quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks details about return values, which is especially important since there is no output schema. The agent cannot know what 'general information' includes, making the description incomplete for effective tool selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter (chain), which already includes a description and default. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns 'general information about a blockchain network'. It uses a specific verb and resource, but does not explicitly differentiate it from sibling tools like get-eth-gas-price or get-latest-blocks, which are more specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-eth-gas-priceA

Get current gas price on Ethereum network

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description must carry the burden. It only states the action without disclosing any behavioral traits such as network dependencies, rate limits, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is direct and front-loaded. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with no parameters, the description is mostly complete. However, it could mention potential network delays or that the price is from a standard oracle.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description correctly omits parameter details as none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Cleary states 'Get current gas price on Ethereum network', which is a specific verb+resource. It distinguishes from sibling tools like get-chain-info and get-latest-blocks by focusing on gas price specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines provided. Does not mention when to use or not use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-latest-blocksC

Get information about recent blocks

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	Number of recent blocks to fetch
`chain`	No	Blockchain network (e.g., eth, solana)	eth

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behaviors like non-destructiveness, data freshness (what 'recent' means), and possible rate limits. It only provides a vague purpose statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no fluff. It is appropriately front-loaded but lacks structured details like parameter clarification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should at least hint at the return format (e.g., list of block objects). It fails to explain what 'recent' means or how results are ordered, making it incomplete for a tool with optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover both parameters fully (count and chain with defaults). The description adds no additional meaning beyond what the schema provides, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets information about recent blocks, which is specific enough given the sibling tools focus on different aspects like chain info or gas price. However, it could be more precise about what information is returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like get-chain-info. The description does not provide any context for appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-solana-accountC

Get account information from Solana blockchain

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	The Solana account address

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits like idempotency, required permissions, or response structure. It only states the action, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise (one sentence) but lacks necessary detail. While brevity is positive, it compromises informativeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and no output schema, the description is too minimal. It does not address error handling, address validity, or the nature of returned 'account information.'

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'address' parameter fully. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Get account information from Solana blockchain,' identifying the blockchain and the action. However, does not differentiate from siblings like get-wallet-balance, which may also return account-level data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., get-wallet-balance). No prerequisites or context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-transactionC

Get details of a specific transaction

ParametersJSON Schema

Name	Required	Description	Default
`txid`	Yes	Transaction ID/hash
`chain`	No	Blockchain network (e.g., eth, solana)	eth

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full burden for behavioral disclosure. It merely states 'get details' without revealing whether it is read-only, requires authentication, has rate limits, or any side effects, which is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 7 words, which is concise but lacking in substantive guidance. It is not verbose, but every word does not add significant value beyond the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description is minimally adequate. However, it does not hint at the return value content, which would help the agent use the output correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already includes descriptions for both parameters (txid and chain), achieving 100% coverage. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches details of a specific transaction, which is a distinct verb+resource combination. However, it does not specify what 'details' includes, such as status, fees, or logs, limiting precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings. There is no mention of prerequisites, context, or alternative tools, leaving the agent without decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-wallet-balanceB

Get the balance of a wallet address on a blockchain

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	The wallet address to check
`chain`	No	Blockchain network (e.g., eth, solana)	eth

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only states it retrieves a balance, but does not disclose how the balance is returned (e.g., units), any required address format, or other behavioral traits. No annotations exist to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks details on the output format (e.g., balance units) and chain values (e.g., no list beyond examples in schema). With no output schema, more context is needed for an agent to correctly interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters adequately. The description adds no further semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('balance of a wallet address on a blockchain'), distinguishing from sibling tools which cover chain info, gas price, blocks, accounts, and transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, or any conditions that affect its use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.0May 28, 2026
- First observedget-chain-info
- First observedget-eth-gas-price
- First observedget-latest-blocks
- First observedget-solana-account
- First observedget-transaction
- First observedget-wallet-balance

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a specific piece of blockchain data (chain info, gas price, blocks, Solana account, transaction, wallet balance) with no apparent overlap in purpose.

Naming Consistency5/5

All tools consistently use the pattern 'get-<specific-resource>' (e.g., get-eth-gas-price, get-transaction), providing clear and predictable naming.

Tool Count5/5

With 6 tools, the server covers essential read operations for blockchain data without being overwhelming or too sparse.

Completeness4/5

The tool set covers common queries for Ethereum and Solana, but lacks support for other major blockchains and some detailed queries (e.g., block by number, transaction receipt), leaving minor gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

blockscout-mcp-server AOAuth
ai.smithery
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Blockchain Web3 & Decentralized Tech Search
244
Token API by The Graph A
com.thegraph.mcp.token-api
Query real-time blockchain token data across EVM and Solana networks. Access token balances, transfers, prices, holders, NFT ownership, DEX swaps, and liquidity pools. Supports Ethereum, Base, Arbitrum, BSC, Polygon, Solana, and more.
Blockchain Web3 & Decentralized Tech Cryptocurrency
2
Nansen A
io.github.hurcanNansen
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
412
Nansen A
io.github.nansen-ai
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
412

Related MCP Servers

MCP Etherscan Server
Blockchain Web3 & Decentralized Tech
crazyrabbitLTC
A
license
A
quality
D
maintenance
Facilitates interaction with Ethereum blockchain data via Etherscan's API, providing real-time access to balances, transactions, token transfers, contract ABIs, gas prices, and ENS name resolutions.
Updated 2 years ago (2024-12-31 17:34 UTC)
6
26
30
MIT
MCP Etherscan Server
Blockchain Web3 & Decentralized Tech
5ajaki
A
license
A
quality
D
maintenance
Provides Ethereum blockchain data tools via Etherscan's API, enabling users to check ETH balances, view transactions, track token transfers, fetch contract ABIs, monitor gas prices, and resolve ENS names.
Updated 2 years ago (2025-01-23 06:00 UTC)
6
26
1
MIT
ChainFETCH MCP Serverofficial
Vector Databases Blockchain RAG Systems
chainfetch
A
license
C
quality
D
maintenance
Enables AI-powered analysis of Ethereum blockchain data through semantic search, natural language queries, and structured filtering. Provides comprehensive access to addresses, transactions, blocks, tokens, and smart contracts with real-time blockchain intelligence.
Updated a year ago (2025-08-23 09:21 UTC)
26
16
1
MIT
EVM MCP Server
Blockchain Web3 & Decentralized Tech Developer Tools
JamesANZ
A
license
A
quality
D
maintenance
Provides comprehensive access to Ethereum Virtual Machine (EVM) JSON-RPC methods for querying blockchain data, executing smart contract calls, and interacting with any EVM-compatible network including Ethereum, Polygon, Arbitrum, and more. Enables users to check balances, analyze transactions, estimate gas, retrieve logs, and perform blockchain operations through natural language.
Updated 2 months ago (2026-07-18 11:00 UTC)
19
20
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GetBlock-io/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP GetBlock Server

Features

Installation

Option 1: Standard Node.js Installation

Option 2: Using Docker

Development

Use with Claude Desktop, Cursor, or other IDE

Option 1: Direct Launch via Node.js

Option 2: Launch via Docker

Available Tools

Detailed Tool Descriptions

get-chain-info

get-wallet-balance

get-transaction

Access Token Priority Order

Architecture & Technology Stack

Supported Networks

Primary Networks

Future Expansions

Examples of Usage

Checking ETH Balance

Viewing Transaction Details

Getting Current Gas Price

Implementation Details

Server Architecture

Code Structure

Troubleshooting

API Connection Issues

Invalid Response Format

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

ChainFETCH MCP Serverofficial

Latest Blog Posts

MCP directory API