blockscout-mcp-server
Server Details
Provide AI agents and automation tools with contextual access to blockchain data including balance…
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- blockscout/mcp-server
- GitHub Stars
- 40
- Server Listing
- Blockscout MCP Server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 16 of 16 tools scored. Lowest: 3.5/5.
Each tool targets a distinct aspect of blockchain data (addresses, blocks, transactions, tokens, NFTs, contracts, chains, raw API). No overlapping purposes; clear differentiation between similar tools like get_transactions_by_address and get_token_transfers_by_address.
Most tools follow a 'verb_noun' pattern (e.g., get_address_info, lookup_token_by_symbol). However, 'direct_api_call' and '__unlock_blockchain_analysis__' deviate from the standard get_/lookup_ prefix, causing minor inconsistencies.
16 tools is well-scoped for a blockchain explorer MCP server. It covers all major data retrieval areas without being overwhelming or too sparse.
The tool set covers core blockchain data (addresses, blocks, transactions, tokens, NFTs, contracts). Missing features like event logs or direct internal transaction querying are partially addressed by the raw API tool, but could be more explicit.
Available Tools
16 toolsdirect_api_callDirect Blockscout API CallARead-onlyInspect
Call a raw Blockscout API endpoint for advanced or chain-specific data.
Do not include query strings in ``endpoint_path``; pass all query parameters via
``query_params`` to avoid double-encoding.
**SUPPORTS PAGINATION**: If response includes 'pagination' field,
use the provided next_call to get additional pages (GET only).
Supports POST requests with a JSON body for endpoints like JSON RPC.
Returns:
ToolResponse[Any]: Must return ToolResponse[Any] (not ToolResponse[BaseModel])
because specialized handlers can return lists or other types that don't inherit
from BaseModel. The dispatcher system supports flexible data structures.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | The pagination cursor from a previous response to get the next page of results. | |
| method | No | HTTP method used for the upstream call. Use POST with json_body. | GET |
| chain_id | Yes | The ID of the blockchain | |
| json_body | No | JSON request body for POST requests. | |
| query_params | No | Optional query parameters forwarded to the Blockscout API. | |
| endpoint_path | Yes | The Blockscout API path to call (e.g., '/api/v2/stats'); do not include query strings. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is clear. The description adds beyond that: pagination behavior, method support, double-encoding warning, and return type flexibility. This is valuable context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: core purpose first, then usage warnings, then pagination, then method support, then return type. Every sentence adds necessary information without redundancy. Front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema exists), the description covers all key aspects: what it does, how to use parameters correctly, pagination, method flexibility, and return type rationale. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic context: endpoint_path should not include query strings, query_params for parameters, json_body for POST, cursor for pagination, and method defaults. It also explains return type. This significantly improves understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Call a raw Blockscout API endpoint for advanced or chain-specific data.' This distinguishes it from sibling tools that are specific endpoint wrappers, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: avoid query strings in endpoint_path, use query_params, support for POST with json_body, and pagination handling. While it doesn't explicitly contrast with siblings, the 'advanced' qualifier implies it's for cases not covered by other tools. A minor gap but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_address_by_ens_nameGet Address by ENS NameARead-onlyInspect
Useful for when you need to convert an ENS domain name (e.g. "blockscout.eth") to its corresponding Ethereum address.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ENS domain name to resolve |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds the core conversion behavior but does not disclose additional traits like error handling, rate limits, or return format. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action. It is concise and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the existence of an output schema, and clear annotations, the description sufficiently captures the tool's purpose. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not provide additional semantic detail beyond what the schema already offers for the parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts an ENS domain name to an Ethereum address, specifying the verb 'convert' and the resource. It distinguishes from sibling tools like get_address_info, which likely work with raw addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to resolve an ENS name, but it does not explicitly mention when not to use it or suggest alternatives among the siblings. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_address_infoGet Address InformationARead-onlyInspect
Get comprehensive information about an address, including:
- Address existence check
- Native token (ETH) balance (provided as is, without adjusting by decimals)
- First transaction details (block number and timestamp) for age calculation
- ENS name association (if any)
- Contract status (whether the address is a contract, whether it is verified)
- Proxy contract information (if applicable): determines if a smart contract is a proxy contract (which forwards calls to implementation contracts), including proxy type and implementation addresses
- Token details (if the contract is a token): name, symbol, decimals, total supply, etc.
Essential for address analysis, contract investigation, token research, and DeFi protocol analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Address to get information about | |
| chain_id | Yes | The ID of the blockchain |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details beyond annotations, such as ETH balance being 'provided as is, without adjusting by decimals,' detection of proxy contracts with proxy type and implementation addresses, and inclusion of first transaction details for age calculation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a bulleted list to enumerate returned information without unnecessary repetition. It is front-loaded with the main purpose. While effective, it could be slightly better structured by separating the list more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description sufficiently explains return values. It covers key aspects like address validity, balance, ENS, contract status, proxy info, and token details. However, it does not mention any limitations, such as supported chains or rate limits, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with brief descriptions for both parameters ('Address to get information about' and 'The ID of the blockchain'). The tool description focuses on output and does not add extra semantic meaning to the parameters themselves, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get comprehensive information about an address' and lists specific data points, making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools like get_address_by_ens_name or get_contract_abi, which more narrowly focus on specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is 'Essential for address analysis, contract investigation, token research, and DeFi protocol analysis,' implying appropriate use cases. However, it lacks explicit guidance on when to avoid this tool in favor of more specific siblings or any constraints on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_block_infoGet Block InformationARead-onlyInspect
Get block information like timestamp, gas used, burnt fees, transaction count etc. Can optionally include the list of transaction hashes contained in the block. Transaction hashes are omitted by default; request them only when you truly need them, because on high-traffic chains the list may exhaust the context.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes | The ID of the blockchain | |
| number_or_hash | Yes | Block number or hash | |
| include_transactions | No | If true, includes a list of transaction hashes from the block. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, making the safety profile clear. The description adds critical behavioral context: the risk that including transaction hashes may exhaust the context on high-traffic chains. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no superfluous words. Front-loads the core purpose and fields, then succinctly covers the optional parameter and its trade-off. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values don't need to be listed), the description covers all essential aspects: what data is returned, the optional parameter's behavior, and a key warning. It is sufficiently complete for agents to decide when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds meaningful value by explaining the default behavior of include_transactions (omitted by default) and the rationale for the default, which aids decision-making beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves block information (timestamp, gas used, burnt fees, transaction count), and distinguishes it from siblings like get_block_number or get_transaction_info. The optional inclusion of transaction hashes is explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the include_transactions parameter ('only when you truly need them') and warns about potential context exhaustion on high-traffic chains. However, it does not explicitly contrast with sibling tools like get_transactions_by_address or direct_api_call for similar tasks, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_block_numberGet Block NumberARead-onlyInspect
Retrieves the block number and timestamp for a specific date/time or the latest block.
Use when you need a block height for a specific point in time (e.g., "block at 2024-01-01")
or the current chain tip. If `datetime` is provided, finds the block immediately
preceding that time. If omitted, returns the latest indexed block.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes | The ID of the blockchain | |
| datetime | No | The date and time (ISO 8601 format, e.g. 2025-05-22T23:00:00.00Z) to find the block for. If omitted, returns the latest block. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds behavioral context, such as that the block returned is the one immediately preceding the given datetime, and that omitting datetime returns the latest indexed block. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences, no wasted words, and front-loads the core purpose. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (not shown), the description need not explain return values. It fully explains input behavior and edge cases (datetime provided vs omitted). For a simple two-parameter tool, the description is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the datetime parameter's format (ISO 8601), its effect, and the default behavior. It also implies chain_id is required to identify the blockchain, which is clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the block number and timestamp for a specific date/time or the latest block. It uses a specific verb ('Retrieves') and resource ('block number and timestamp'), and distinguishes from siblings like 'get_block_info' which retrieves block details by block number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('Use when you need a block height for a specific point in time or the current chain tip') and explains the behavior with and without the 'datetime' parameter. It does not explicitly state when not to use or mention alternatives, but the sibling list includes 'get_block_info' as an alternative for querying by block number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chains_listGet List of ChainsARead-onlyInspect
Get supported blockchain chains with their chain IDs.
Use this when another tool needs a supported `chain_id` and only the chain name,
ecosystem, or native currency is known. Prefer a narrow `query` to avoid returning
the full registry to the agent. Do not rely on partial numeric chain ID queries such
as `1`, because matching is substring-based and may return many chains.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional case-insensitive substring filter applied to chain name, chain ID, native currency, and ecosystem. Prefer narrow text terms over partial numeric chain IDs because matching is substring-based. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false; description adds that matching is case-insensitive substring-based, warning about potential broad results from numeric queries. This enriches transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each purposeful: purpose, usage context, behavior warning. No unnecessary words; efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description need not detail returns. It sufficiently covers query parameter semantics, usage guidance, and behavioral traits. Complete for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the substring matching behavior and advising against partial numeric queries, which is not fully captured in the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get supported blockchain chains with their chain IDs,' a clear verb+resource. While not explicitly differentiating from siblings, its role is distinct among the listed sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (when another tool needs a supported chain_id from partial info), and provides specific guidance: prefer narrow query, avoid partial numeric chain IDs due to substring matching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contract_abiGet Contract ABIARead-onlyInspect
Get smart contract ABI (Application Binary Interface). An ABI defines all functions, events, their parameters, and return types. The ABI is required to format function calls or interpret contract data.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Smart contract address | |
| chain_id | Yes | The ID of the blockchain |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds value by explaining what the ABI contains and its purpose, going beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, definition, and usage context. No wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (not shown but indicated). Description explains the concept of ABI, making it understandable. Could mention source or retrieval method, but adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for both parameters (address and chain_id). Description does not add extra meaning beyond what schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get smart contract ABI (Application Binary Interface).' It explains what an ABI is and distinguishes from sibling tools like read_contract or inspect_contract_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions when ABI is needed ('format function calls or interpret contract data') but does not explicitly guide when to use this tool over alternatives like read_contract or inspect_contract_code. Implicit context is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tokens_by_addressGet Tokens by AddressARead-onlyInspect
Get comprehensive ERC20 token holdings for an address with enriched metadata and market data.
Returns detailed token information including contract details (name, symbol, decimals), market metrics (exchange rate, market cap, volume), holders count, and actual balance (provided as is, without adjusting by decimals).
Essential for portfolio analysis, wallet auditing, and DeFi position tracking.
**SUPPORTS PAGINATION**: If response includes 'pagination' field, use the provided next_call to get additional pages.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | The pagination cursor from a previous response to get the next page of results. | |
| address | Yes | Wallet address | |
| chain_id | Yes | The ID of the blockchain |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds value beyond annotations by disclosing that the balance is provided 'as is, without adjusting by decimals' and detailing pagination behavior. This context is not available from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. It front-loads the main action and uses bold for emphasis on pagination. While it could be slightly more compact, it is well-structured and easy to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered externally. The description explains the kind of data returned (contract details, market metrics, balance) and mentions pagination. For a read-only portfolio analysis tool, this provides sufficient context for an agent to understand its capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter thoroughly. The description does not add additional semantic meaning to the parameters beyond what the schema provides. Thus, a baseline score of 3 is appropriate as the description adds no extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get comprehensive ERC20 token holdings for an address with enriched metadata and market data.' It specifies the verb (get), resource (ERC20 token holdings), and scope (for an address with enriched data). The inclusion of 'ERC20' and 'market data' effectively distinguishes this tool from siblings like get_token_transfers_by_address or nft_tokens_by_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating 'Essential for portfolio analysis, wallet auditing, and DeFi position tracking.' It also explicitly mentions pagination support. Though it doesn't explicitly state when not to use this tool or list alternatives, the sibling list and the focused purpose implicitly guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_token_transfers_by_addressGet Token Transfers by AddressARead-onlyInspect
Get ERC-20 token transfers for an address within a specific time range.
Use cases:
- `get_token_transfers_by_address(address, age_from)` - get all transfers of any ERC-20 token to/from the address since the given date up to the current time
- `get_token_transfers_by_address(address, age_from, age_to)` - get all transfers of any ERC-20 token to/from the address between the given dates
- `get_token_transfers_by_address(address, age_from, age_to, token)` - get all transfers of the given ERC-20 token to/from the address between the given dates
**SUPPORTS PAGINATION**: If response includes 'pagination' field, use the provided next_call to get additional pages.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | An ERC-20 token contract address to filter transfers by a specific token. If omitted, returns transfers of all tokens. | |
| age_to | No | End date and time (e.g 2025-05-22T22:30:00.00Z). Can be omitted to get all transfers up to the current time. | |
| cursor | No | The pagination cursor from a previous response to get the next page of results. | |
| address | Yes | Address which either transfer initiator or transfer receiver | |
| age_from | Yes | Start date and time (e.g 2025-05-22T23:00:00.00Z). | |
| chain_id | Yes | The ID of the blockchain |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds valuable behavioral info: pagination support and that it returns transfers of 'any ERC-20 token' or specific token. No contradictions. This supplements the annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a clear note on pagination. Every sentence serves a purpose, and it is concise without unnecessary detail. It front-loads the core purpose and then provides examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage, output schema exists, and annotations provide safety context, the description fully covers pagination and all use cases. No gaps; it completes the understanding needed for a read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description shows usage patterns but does not add new semantic meaning beyond the schema's parameter descriptions. It reinforces existing info, but doesn't elevate understanding of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get ERC-20 token transfers for an address within a specific time range.' It distinguishes from sibling tools like get_transactions_by_address and nft_tokens_by_address by specifying token transfers. The verb 'Get' and resource 'token transfers' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use case patterns with parameter combinations, e.g., `get_token_transfers_by_address(address, age_from)` and pagination guidance. It doesn't explicitly state when not to use or alternatives, but the sibling names provide context. Overall, it gives clear context for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transaction_infoGet Transaction InformationARead-onlyInspect
Get comprehensive transaction information.
Unlike standard eth_getTransactionByHash, this tool returns enriched data including decoded input parameters, detailed token transfers with token metadata, transaction fee breakdown (priority fees, burnt fees) and categorized transaction types.
By default, the raw transaction input is omitted if a decoded version is available to save context; request it with `include_raw_input=True` only when you truly need the raw hex data.
Essential for transaction analysis, debugging smart contract interactions, tracking DeFi operations.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes | The ID of the blockchain | |
| transaction_hash | Yes | Transaction hash | |
| include_raw_input | No | If true, includes the raw transaction input data. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, destructiveHint false. The description adds behavioral traits: default omission of raw input to save context, and details of enriched data beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: first sentence states purpose, subsequent sentences add essential details. No extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of enriched transaction data, annotations, and the presence of an output schema, the description provides sufficient context: what is returned, default behaviors, and use cases. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, but the description adds value by explaining the default behavior of include_raw_input and the condition for using it. This aids correct parameter invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves comprehensive transaction information, enriching beyond standard eth_getTransactionByHash. It distinguishes itself from sibling tools by listing specific enrichments (decoded input, token transfers, fee breakdown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states use cases: transaction analysis, debugging, DeFi tracking. It also advises when to use the include_raw_input parameter ('only when you truly need the raw hex data'). No explicit when-not is given, but the tool is the sole transaction info tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transactions_by_addressGet Transactions by AddressARead-onlyInspect
Retrieves native currency transfers and smart contract interactions (calls, internal txs) for an address.
**EXCLUDES TOKEN TRANSFERS**: Filters out direct token balance changes (ERC-20, etc.). You'll see calls *to* token contracts, but not the `Transfer` events. For token history, use `get_token_transfers_by_address`.
A single tx can have multiple records from internal calls; use `internal_transaction_index` for execution order.
Requires an `age_from` date to scope results for performance and relevance.
Use cases:
- `get_transactions_by_address(address, age_from)` - get all txs to/from the address since a given date.
- `get_transactions_by_address(address, age_from, age_to)` - get all txs to/from the address between given dates.
- `get_transactions_by_address(address, age_from, age_to, methods)` - get all txs to/from the address between given dates, filtered by method.
**SUPPORTS PAGINATION**: If response includes 'pagination' field, use the provided next_call to get additional pages.
| Name | Required | Description | Default |
|---|---|---|---|
| age_to | No | End date and time (e.g 2025-05-22T22:30:00.00Z). | |
| cursor | No | The pagination cursor from a previous response to get the next page of results. | |
| address | Yes | Address which either sender or receiver of the transaction | |
| methods | No | A method signature to filter transactions by (e.g 0x304e6ade) | |
| age_from | Yes | Start date and time (e.g 2025-05-22T23:00:00.00Z). | |
| chain_id | Yes | The ID of the blockchain |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description adds critical behavioral details: exclusion of token transfers, internal transaction handling with internal_transaction_index, requirement of age_from for performance, and pagination support. This provides rich context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and examples. Every sentence adds value without redundancy. At approximately 10 sentences, it is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the complexity of 6 parameters and siblings, the description covers all necessary aspects: return content, exclusions, parameter requirements, pagination, and usage patterns. It leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so baseline is 3. The description adds value by explaining the use of age_from as a required filter and showing example combinations, though it does not add significantly beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves native currency transfers and smart contract interactions for an address, and clearly distinguishes it from token transfers by directing to get_token_transfers_by_address. The verb 'retrieves' is specific and the resource 'transactions by address' is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases with different parameter combinations, explains when to use vs. the sibling tool for token history, and mentions pagination. It could be improved by explicitly stating when not to use this tool, but overall it gives strong context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspect_contract_codeInspect Contract CodeARead-onlyInspect
Inspects a verified contract's source code or metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The address of the smart contract. | |
| chain_id | Yes | The ID of the blockchain. | |
| file_name | No | The name of the source file to inspect. If omitted, returns contract metadata and the list of source files. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; description adds the verification constraint and scope (source code or metadata), providing moderate additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers core function and verification requirement, but could be more explicit about what happens if contract is unverified. Output schema covers return values, so that gap is filled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds no extra parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states verb ('inspects') and resource ('verified contract's source code or metadata'), distinguishing it from siblings like get_contract_abi or read_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as get_contract_abi or read_contract, missing explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_token_by_symbolLookup Token by SymbolARead-onlyInspect
Search for token addresses by symbol or name. Returns multiple potential
matches based on symbol or token name similarity. Only the first
``TOKEN_RESULTS_LIMIT`` matches from the Blockscout API are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token symbol or name to search for | |
| chain_id | Yes | The ID of the blockchain |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool returns multiple matches and is limited to the first TOKEN_RESULTS_LIMIT from the Blockscout API. This adds value beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) by explaining search behavior and limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey purpose and key behavior without redundancy. Information is front-loaded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with two parameters and an output schema, the description adequately covers purpose, behavior (multiple matches, limit), and context. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little meaning beyond the schema. The description repeats that the symbol parameter accepts both symbol or name, but does not provide examples or additional constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for token addresses by symbol or name, and specifies it returns multiple potential matches. This differentiates it from sibling tools like get_tokens_by_address which searches by address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for symbol/name-based lookup but does not explicitly state when to use or avoid this tool. The sibling context shows no direct alternative for symbol search, so the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nft_tokens_by_addressGet NFT Tokens by AddressARead-onlyInspect
Retrieve NFT tokens (ERC-721, ERC-404, ERC-1155) owned by an address, grouped by collection.
Provides collection details (type, address, name, symbol, total supply, holder count) and individual token instance data (ID, name, description, external URL, metadata attributes).
Essential for a detailed overview of an address's digital collectibles and their associated collection data.
**SUPPORTS PAGINATION**: If response includes 'pagination' field, use the provided next_call to get additional pages.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | The pagination cursor from a previous response to get the next page of results. | |
| address | Yes | NFT owner address | |
| chain_id | Yes | The ID of the blockchain |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, destructiveHint. Description adds valuable context: grouping by collection, pagination support, and details on returned data (collection and token instance fields). This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs efficiently cover purpose, data structure, and pagination. No unnecessary words or repetition. Could be slightly more structured (e.g., bullet points) but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (NFTs, pagination, collections) and presence of output schema, the description is reasonably complete. It covers token types, grouping, and pagination. Missing explicit mention of filtering or edge cases, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds marginal meaning. It mentions pagination cursor and grouping, but the schema already defines parameters clearly. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves NFT tokens owned by an address, grouped by collection, specifying token standards (ERC-721, ERC-404, ERC-1155). This distinguishes it from sibling tools like get_tokens_by_address (which likely returns all token types) and get_token_transfers_by_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for a detailed overview of digital collectibles but does not explicitly state when not to use it or mention alternatives. Pagination support is noted, but no guidance on when to choose this over siblings like get_tokens_by_address for non-NFT token queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_contractRead from ContractARead-onlyInspect
Calls a smart contract function (view/pure, or non-view/pure simulated via eth_call) and returns the
decoded result.
This tool provides a direct way to query the state of a smart contract.
Example:
To check the USDT balance of an address on Ethereum Mainnet, you would use the following arguments:
{
"tool_name": "read_contract",
"params": {
"chain_id": "1",
"address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
"abi": {
"constant": true,
"inputs": [{"name": "_owner", "type": "address"}],
"name": "balanceOf",
"outputs": [{"name": "balance", "type": "uint256"}],
"payable": false,
"stateMutability": "view",
"type": "function"
},
"function_name": "balanceOf",
"args": "["0xF977814e90dA44bFA03b6295A0616a897441aceC"]"
}
}
| Name | Required | Description | Default |
|---|---|---|---|
| abi | Yes | The JSON ABI for the specific function being called. This should be a dictionary that defines the function's name, inputs, and outputs. The function ABI can be obtained using the `get_contract_abi` tool. | |
| args | No | A JSON string containing an array of arguments. Example: "["0xabc..."]" for a single address argument, or "[]" for no arguments. Order and types must match ABI inputs. Addresses: use 0x-prefixed strings; Numbers: prefer integers (not quoted); numeric strings like "1" are also accepted and coerced to integers. Bytes: keep as 0x-hex strings. | [] |
| block | No | The block identifier to read the contract state from. Can be a block number (e.g., 19000000) or a string tag (e.g., 'latest'). Defaults to 'latest'. | latest |
| address | Yes | Smart contract address | |
| chain_id | Yes | The ID of the blockchain | |
| function_name | Yes | The symbolic name of the function to be called. This must match the `name` field in the provided ABI. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description discloses that it can simulate non-view/pure functions via eth_call and returns decoded results, adding behavioral context. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs and an example. The purpose is front-loaded. Every sentence adds value, though the example is lengthy but necessary for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects) and presence of output schema, the description is fairly complete, explaining the core functionality and providing an example. It does not cover error handling or edge cases, but adequately supports an AI agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description provides a detailed example and explains argument formatting (addresses, numbers, bytes) which adds meaning beyond the schema. The example clarifies how to structure the ABI and args.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calls smart contract functions and returns decoded results, using specific verbs and resource. However, it lacks explicit differentiation from sibling tools like direct_api_call or get_contract_abi, which also perform similar queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying state but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives. The phrase 'direct way to query state' is vague and does not help in choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
__unlock_blockchain_analysis__Unlock Blockchain AnalysisARead-onlyInspect
Mandatory initialization step for any session against the Blockscout MCP server.
Returns server reference data plus the `blockscout-analysis` skill pointer and URI
resolution rule.
MANDATORY FOR AI AGENTS: Call this tool first in every session. The returned payload
identifies where the operating rules and analysis framework live and how to read
referenced skill files before executing further tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The main data payload of the tool's response. |
| notes | No | A list of important contextual notes, such as warnings about data truncation or data quality issues. |
| pagination | No | Pagination information, present only if the 'data' is a single page of a larger result set. |
| content_text | No | Optional human-readable summary used for MCP content responses. |
| instructions | No | A list of suggested follow-up actions or instructions for the LLM to plan its next steps. |
| data_description | No | A list of notes explaining the structure, fields, or conventions of the 'data' payload. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context beyond annotations by detailing the returned payload (server reference data, skill pointer, URI resolution rule) and its purpose for subsequent skill file reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the key mandate in bold. It efficiently communicates the essential information without redundancy. Minor improvement could be even more brevity, but current form is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, comprehensive annotations, and a simple initialization purpose, the description fully covers what an agent needs: why, when, and what to expect from the output. The output schema may provide additional structure, but the description sufficiently frames the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the description has no need to add parameter detail. Baseline is 4 for parameter-free tools; the description appropriately focuses on the tool's purpose rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a mandatory initialization step, explicitly listing what it returns (server reference data, skill pointer, URI resolution rule). This specific verb-resource combination ('unlock blockchain analysis') is distinguished from sibling data-retrieval tools by its setup role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs AI agents to 'Call this tool first in every session' and explains why (to get operating rules and analysis framework). This is unambiguous when-to-use guidance with no need for exclusions since it's mandatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.