Tatum MCP Server

Official

by tatumio

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
There is significant overlap and ambiguity among tools, especially in the fee estimation category where multiple tools (bsc_estimate_gas, celo_estimate_gas, eth_estimate_gas, estimate_gas, etc.) serve similar purposes for different blockchains, making it difficult for an agent to choose the correct one without deep chain-specific knowledge. The blockchain data tools also have overlapping functionalities, such as get_balances_v4, get_wallet_balances_v4, and get_wallet_portfolio_v4, which can confuse agents about which to use for balance queries.
Naming Consistency3/5
The naming is mixed with some consistency within categories but overall inconsistent patterns. Fee estimation tools use a mix of chain-specific prefixes (e.g., bsc_estimate_gas, eth_estimate_gas) and generic names (estimate_gas, estimate_fee_blockchain), while blockchain data tools follow a get_*_v4 pattern but with variations like check_owner_v4. Gateway tools use a consistent gateway_* prefix, but the overall set lacks a unified naming convention.
Tool Count2/5
With 26 tools, the count is too high for the apparent scope of blockchain data and fee estimation, leading to redundancy and complexity. Many tools could be consolidated (e.g., multiple chain-specific gas estimators into a unified tool), making the set feel bloated and difficult for agents to navigate efficiently.
Completeness4/5
The tool set covers a broad range of blockchain operations including fee estimation, data queries (balances, owners, metadata, collections), and gateway functionalities, with good coverage across multiple blockchains. However, there are minor gaps such as lack of tools for transaction submission or smart contract interaction, which might limit full lifecycle coverage but are not critical for the data-focused domain.
Average 3.5/5 across 26 of 26 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions '[fee_estimation] 1 credit per API call,' which hints at cost and operation type, but lacks details on permissions, rate limits, error handling, or response format. For a tool with no annotation coverage, this is insufficient to fully inform 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but could be better structured. It front-loads the purpose but includes verbose details like fee units and blockchain list in a single sentence, making it slightly cluttered. While not wasteful, it lacks optimal clarity and flow for quick comprehension.
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 annotations and no output schema, the description is incomplete. It covers the basic operation and parameters but omits critical behavioral aspects (e.g., response format, error cases) and usage context. For a tool with 1 parameter and no structured output, more detail is needed to adequately guide an AI agent.
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 has 100% description coverage, clearly defining the 'chain' parameter with an enum. The description adds minimal semantics by listing supported blockchains (Bitcoin, Dogecoin, Ethereum, Litecoin), which loosely maps to the enum values. However, it does not explain parameter interactions or usage beyond what the schema provides, resulting in a baseline score.
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's purpose: 'Get the recommended fee/gas price for a blockchain.' It specifies the verb ('Get') and resource ('fee/gas price'), and includes scope details like fee units and supported blockchains. However, it does not explicitly differentiate from sibling tools (e.g., 'estimate_fee_blockchain'), which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists supported blockchains but does not mention sibling tools like 'estimate_fee_blockchain' or explain use cases, prerequisites, or exclusions. This lack of comparative context limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions '50 credits per API call' (cost information) and lists supported blockchains, but doesn't disclose important behavioral aspects like rate limits, authentication requirements, error conditions, or what the response format looks like (especially since there's no output schema).
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 reasonably concise but poorly structured. It front-loads the API endpoint and cost information before the actual purpose. The blockchain list takes up excessive space and could be summarized. The single run-on sentence could be broken into clearer components for better readability.
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?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'Multi Token' means specifically, how results are structured (grouped by smart contracts), what data is returned, or provide any examples. The cost information is useful but doesn't compensate for missing behavioral and output context.
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 description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions the address parameter indirectly but provides no additional context about format requirements or chain selection guidance.
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's purpose: 'Get Multi Token balances of a wallet address' with the specific action 'Get' and resource 'Multi Token balances'. It distinguishes from siblings like get_balances_v4 by specifying 'Multi Token' grouping by smart contracts, though it could be more explicit about the difference.
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?
The description provides no guidance on when to use this tool versus alternatives like get_balances_v4 or get_nft_balances_v4. It lists supported blockchains but doesn't explain why you'd choose this tool over other balance-checking tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action 'execute an RPC call' but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what the response looks like. For a tool that performs network calls with potential side effects, this is a significant gap.
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, efficient sentence that front-loads the core action. There is zero wasted text, making it easy to parse 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?
Given the complexity of executing arbitrary RPC calls across blockchains, the description is insufficient. No annotations exist, there's no output schema, and it lacks details on supported chains, method validation, or response format. This leaves critical gaps for an agent to use the tool effectively.
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 description coverage is 100%, so the schema already documents all three parameters (chain, method, params). The description adds no additional meaning beyond what's in the schema, such as examples of valid chains or methods. The baseline score of 3 reflects adequate but minimal value added.
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 verb 'execute' and resource 'RPC call on a specific chain', making the purpose understandable. It distinguishes this as a general RPC execution tool versus sibling tools that are chain-specific or perform specialized operations like gas estimation. However, it doesn't explicitly differentiate from all siblings (e.g., gateway_get_* tools).
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. The description doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves a URL but does not disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. This leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand 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?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the returned URL is used for, the format of the response, or any error conditions, which are crucial for a tool that retrieves a gateway URL without structured output documentation.
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 has 100% description coverage, with the 'chain' parameter well-documented. The description adds no additional meaning beyond the schema, such as examples of chain values or format details, so it meets the baseline score of 3 without compensating further.
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 action ('Get') and resource ('gateway URL for a specific chain'), making the purpose evident. However, it does not explicitly differentiate from siblings like 'gateway_get_evm_chains' or 'gateway_get_supported_chains', which might retrieve lists of chains rather than a URL for one chain, so it misses full sibling distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, when this tool is appropriate compared to other gateway-related tools, or any exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks EVM compatibility but doesn't explain what 'EVM-compatible' means, how the check is performed (e.g., via API call, local lookup), potential errors, or the return format. This leaves significant gaps in understanding the tool's behavior.
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 extremely concise—a single, clear sentence that efficiently conveys the tool's purpose without any wasted words. It is front-loaded and easy to parse, making it ideal for quick understanding.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., boolean, detailed compatibility info) or handle edge cases, which is crucial for a tool that checks chain compatibility. The simplicity of the tool (one parameter) doesn't compensate for these omissions.
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 has 100% description coverage, with the 'chain' parameter documented as 'The blockchain to check.' The description adds no additional meaning beyond this, as it doesn't specify format (e.g., chain ID, name) or examples. With high schema coverage, the 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's purpose: 'Check if a chain is EVM-compatible.' It specifies the verb ('Check') and resource ('chain'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'gateway_get_evm_chains' or 'gateway_get_supported_chains,' which reduces the score from a perfect 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools such as 'gateway_get_evm_chains' (which might list EVM chains) or 'gateway_get_supported_chains' (which might list all supported chains), leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'capabilities' but does not specify what information is returned (e.g., tool names, descriptions, parameters), whether it's a read-only operation, or any performance considerations like rate limits. This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence that front-loads the key action ('Get a list'). However, the '[gateway]' prefix is somewhat cryptic and could be integrated more smoothly, slightly reducing clarity. Overall, it is concise with minimal waste.
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 lack of annotations and output schema, the description is incomplete. It does not detail the return format (e.g., list structure, data fields) or behavioral aspects like error handling. For a tool that lists capabilities, more context on output semantics is needed to be fully helpful to an agent.
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 has 100% description coverage, with the parameter 'category' well-documented as an optional filter with an enum list. The description does not add any meaning beyond the schema, as it does not explain parameter usage or effects. With high schema coverage, the 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 verb ('Get') and resource ('list of all available tools and their capabilities'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'gateway_get_supported_chains' or 'gateway_get_evm_chains', which might list specific chain-related tools rather than all available tools. The inclusion of '[gateway]' adds some context but is not fully explanatory.
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?
The description provides no guidance on when to use this tool versus alternatives, such as other 'gateway_' tools or tools for specific blockchain operations. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions '10 credits per API call' (cost implication) and describes what the response contains ('metadata about each specified token, including its name, description, image, and more'). However, it doesn't disclose important behavioral traits like rate limits, error conditions, pagination, or whether this is a read-only operation. The description adds some value but leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured and contains unnecessary information. It begins with API endpoint details and a note for v3 users that doesn't help tool selection. The core purpose is buried in the middle, and the blockchain list is excessively detailed. While all information is technically relevant, the presentation lacks front-loading and contains sentences that don't earn their place for tool selection purposes.
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?
For a tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate but incomplete context. It covers the purpose, supported networks, and response content, but lacks information about error handling, rate limits, and detailed behavioral characteristics. The absence of an output schema means the description should ideally explain return values more thoroughly than it does.
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?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'comma-separated list of IDs' (already in schema) and lists supported blockchain networks (helpful context not in schema). This meets the baseline expectation when schema coverage is high, but doesn't significantly enhance parameter understanding.
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's purpose: 'Get metadata of NFTs (ERC-721 and ERC-1155) or multitokens (ERC-1155 only) by IDs for a given token address.' It specifies the resource (NFT/multitoken metadata), the action (get), and the key parameters (token address and IDs). However, it doesn't explicitly differentiate from sibling tools like 'get_collections_v4' or 'get_nft_balances_v4', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by listing supported blockchains and stating 'To get started: Provide a chain name, token address and comma-separated list of IDs.' However, it doesn't explicitly state when to use this tool versus alternatives like 'get_owners_v4' or 'get_collections_v4', nor does it provide exclusion criteria or prerequisites beyond the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions '10 credits per API call' which indicates a cost/rate limit aspect, adding some value. However, it doesn't describe what the tool returns (e.g., fee structure, units), error conditions, or whether it's a read-only operation. For a tool with zero annotation coverage, this leaves significant behavioral 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?
The description is reasonably concise but could be better structured. It front-loads the credit cost and purpose, but the blockchain list is lengthy and might be better summarized. The sentence structure is somewhat cluttered, though all information appears relevant.
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 tool's complexity (fee estimation across multiple blockchains), no annotations, and no output schema, the description is incomplete. It doesn't explain what the estimated fee includes, the format of the response, or how to interpret results for different transaction types. The blockchain list is helpful but doesn't compensate for missing behavioral and output details.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and context. This meets the baseline expectation for a parameterless tool.
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's purpose: 'Estimate the current fee for different types of transactions' with a specific verb ('Estimate') and resource ('fee'). It distinguishes from siblings like 'get_blockchain_fee' by specifying estimation rather than retrieval, and from gas estimation tools by covering multiple transaction types. However, it doesn't explicitly differentiate from all sibling tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by listing supported blockchains, suggesting this tool should be used for those specific chains. However, it doesn't offer explicit guidance on when to use this versus alternatives like 'estimate_gas' or blockchain-specific gas estimation tools, nor does it mention exclusions or prerequisites beyond the blockchain list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves a list but doesn't disclose behavioral traits like whether it's read-only, if it requires authentication, rate limits, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal. It states what the tool does but lacks context on usage, behavioral transparency, or output details, making it incomplete for effective agent invocation.
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?
The tool has 0 parameters, and the input schema coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, but it doesn't fully compensate for the lack of output schema, so it's not a perfect score.
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 action ('Get a list') and resource ('all supported EVM-compatible chains'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'gateway_get_supported_chains' or 'gateway_is_evm_chain', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions it's a read operation ('Get a list'), but lacks details on response format, pagination, rate limits, or authentication needs. This is inadequate for a tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list includes (e.g., chain IDs, names, types), how it's structured, or any limitations. For a tool with no structured output documentation, this leaves significant gaps.
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?
The tool has 0 parameters, and the schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate as it doesn't introduce confusion or redundancy.
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 action ('Get a list') and resource ('all supported blockchain chains'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'gateway_get_evm_chains' or 'gateway_get_url', which prevents a score of 5.
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 like 'gateway_get_evm_chains' or 'gateway_is_evm_chain'. The description only states what it does, not when it's appropriate, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions cost ('20 credits per API call'), supported blockchains, and some behavioral details like pagination (implied through offset/pageSize parameters) and metadata exclusion options. However, it doesn't cover important aspects like rate limits, error handling, authentication requirements, or what the response structure looks like (no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured with multiple topics mixed together: API version notes, credit costs, supported blockchains, usage instructions, and parameter details. It begins with administrative information rather than the core purpose. The note about v3 API users is unnecessary for tool selection. Sentences like 'Our API lets you search for all tokens on:' followed by a blockchain list could be more concise.
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 6 parameters, no annotations, and no output schema, the description provides moderate coverage. It explains the core functionality, lists supported blockchains, and mentions some parameter behaviors. However, for a tool with pagination, filtering options, and no output schema, it should better explain response structure, error conditions, and practical usage patterns. The completeness is adequate but has clear gaps.
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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds some context about 'excludeMetadata' and 'tokenType' parameters, and mentions Tezos-specific behavior, but doesn't provide significant additional semantic value beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Get all NFTs (ERC-721 and ERC-1155) and multitokens (ERC-1155 only) of your favorite collections!' This specifies the verb ('Get'), resource ('NFTs and multitokens'), and scope ('collections'). It doesn't explicitly differentiate from sibling tools like 'get_nft_balances_v4' or 'get_multi_token_balance_v4', but the focus on collections rather than wallets provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by listing supported blockchains and stating 'To get started: Provide a chain name and comma-separated list of collection addresses.' However, it doesn't explicitly say when to use this tool versus alternatives like 'get_nft_balances_v4' (which appears to be wallet-focused) or 'get_owners_v4'. The guidance is implied rather than explicit about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API cost ('50 credits per API call'), which is useful context not in the schema. However, it doesn't describe other important behaviors like pagination mechanics (implied by offset/pageSize but not explained), rate limits, authentication requirements, error conditions, or what the response format looks like (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured. It includes irrelevant information for an AI agent (API version migration note for v3 users, blockchain list formatting issues). The core purpose is buried after this noise. Sentences like 'Our API lets you search for all token owners on:' followed by a messy list reduce clarity. It could be significantly condensed and front-loaded with the essential purpose.
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 complexity (5 parameters, no annotations, no output schema), the description is moderately complete. It covers the basic purpose, supported blockchains, and parameter hints, but lacks critical details: no explanation of pagination behavior (offset/pageSize usage), no response format description, and no error handling or rate limit info. The API cost mention is helpful, but overall it leaves gaps for a tool with multiple parameters and no structured output documentation.
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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'chain name and address' and 'tokenId' for specific NFTs, but doesn't provide additional syntax, format details, or examples beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Get all addresses that own your favorite token (ERC-20, ERC-721 or ERC-1155)!' It specifies the verb ('get'), resource ('addresses that own your favorite token'), and token types. However, it doesn't explicitly differentiate from sibling tools like 'check_owner_v4' or 'get_nft_balances_v4', which likely have related but distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by listing supported blockchains and stating 'To get started: Provide a chain name and address of any fungible token, NFT or multitoken collection.' It implies when to use this tool (to find token owners) but doesn't explicitly contrast with alternatives like 'check_owner_v4' or specify when not to use it (e.g., for checking single ownership vs. listing all owners).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a read-only operation (implied by 'Get'), includes cost ('2 credits per API call'), and sources data from specific URLs. However, it lacks details on rate limits, error handling, or output format, leaving gaps in transparency for a tool with no structured annotations.
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 concise and front-loaded, starting with the core purpose. The two sentences are efficient, with the first stating the action and the second providing source URLs. There's minimal waste, though the bracketed '[fee_estimation]' could be integrated more smoothly.
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 complexity (simple estimation with no parameters) and lack of output schema, the description is moderately complete. It explains what the tool does and its data sources but omits details on return values, error cases, or integration context. This is adequate for a basic tool but has clear gaps in full context.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. It earns a baseline 4 because the schema fully covers parameters, and the description doesn't need to compensate.
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's purpose: 'Get an estimated gas price and the number of gas units needed for an Elrond transaction.' It specifies the verb ('Get') and resource ('gas price' and 'gas units'), though it doesn't explicitly differentiate from sibling tools like 'eth_estimate_gas' or 'bsc_estimate_gas' beyond mentioning Elrond. This makes it clear but not fully sibling-distinctive.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions '[fee_estimation] 2 credits per API call,' which hints at cost, but doesn't specify contexts, prerequisites, or exclusions. Without explicit usage rules or comparisons to siblings, it offers minimal practical direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: cost ('50 credits per API call'), supported blockchains, and metadata return conditions for Solana/Algorand. However, it misses details like rate limits, error handling, pagination, or response format. The information is useful but incomplete for a tool with potential complexity.
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 appropriately sized and front-loaded with the core purpose. It efficiently lists supported blockchains and metadata conditions in a structured manner. However, the credit cost mention could be integrated more smoothly, and some sentences are lengthy, slightly reducing readability.
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 no annotations and no output schema, the description provides moderate completeness. It covers purpose, cost, blockchains, and metadata nuances, but lacks details on response structure, error cases, or performance considerations. For a tool with 2 parameters and no structured output, this is adequate but leaves gaps for the agent.
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 description coverage is 100%, so the schema already documents both parameters (address and chain) adequately. The description adds no additional parameter semantics beyond what the schema provides, such as format specifics or validation rules. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose: 'Get all NFTs that a blockchain address holds' and specifies they are 'grouped by the smart contracts they were minted on.' It distinguishes from siblings like get_balances_v4 (general balances) and get_collections_v4 (collections data), but doesn't explicitly name alternatives. The verb 'get' and resource 'NFTs' are specific, though it could be more precise about the grouping aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by listing supported blockchains and noting metadata behavior differences for Solana and Algorand. However, it lacks explicit guidance on when to use this tool versus alternatives like get_metadata_v4 for metadata or get_owners_v4 for ownership checks. No clear exclusions or prerequisites are stated, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a fee estimation tool (10 credits per API call), which is useful cost information. However, it doesn't mention other behavioral traits like rate limits, authentication requirements, error conditions, or what the response format looks like. The description adds some value but leaves 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?
The description is moderately concise but has structural issues. The first sentence clearly states the purpose, but the second sentence about 'New endpoint which is unifying...' is awkwardly phrased. The list of supported chains is presented as a run-on sentence rather than structured, making it harder to parse. Some sentences could be more efficiently worded.
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 no annotations, no output schema, and 0 parameters, the description provides adequate basic information about purpose and supported chains. However, for a tool with cost implications (10 credits per call) and multiple sibling alternatives, it should better explain the unification aspect and what exactly it returns. The lack of output schema means the description should ideally mention response format, which it doesn't.
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?
The input schema has 0 parameters with 100% coverage, so the schema already fully documents the lack of parameters. The description doesn't need to explain parameters, but it does mention this is for 'a transaction' without specifying how transaction details are provided. Since there are no parameters, a baseline of 4 is appropriate as the description doesn't need to compensate for schema gaps.
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's purpose: 'Get an estimated gas price (wei) and the number of gas units needed for a transaction.' It specifies the verb ('Get') and resource ('estimated gas price' and 'gas units'), and mentions it's a fee estimation endpoint. However, it doesn't explicitly differentiate from sibling tools like 'bsc_estimate_gas' or 'eth_estimate_gas', which appear to be chain-specific versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for gas estimation across multiple supported chains, listing them explicitly. It implies this is a unified endpoint replacing chain-specific ones, suggesting it should be preferred over siblings like 'bsc_estimate_gas'. However, it doesn't explicitly state when NOT to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: cost ('100 credits per API call'), supported blockchains, handling of future/past inputs (e.g., 'If you pass a block number that is in the future...'), and constraints on filter usage. However, it lacks details on error handling, rate limits, or authentication needs, which are important for a paid API tool.
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 front-loaded with key information (purpose, cost, supported chains) but becomes verbose with repetitive explanations of input handling (e.g., future/past scenarios stated twice). Some sentences could be condensed for better efficiency, though overall it remains reasonably structured.
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 complexity (5 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose, usage, behaviors, and constraints adequately, but lacks details on output format, error responses, or integration with sibling tools. For a tool with no output schema, more information on return values would be beneficial.
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 description coverage is 100%, so the schema already documents all parameters. The description adds some context by explaining filter constraints (e.g., 'combination of the filters is not allowed') and input handling rules (e.g., future/past values), but does not provide significant additional semantics beyond what the schema descriptions offer. This meets the baseline for high schema coverage.
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's purpose: 'Get native balances for a specific wallet addresses by time on the following blockchains.' It specifies the verb ('Get'), resource ('native balances'), and scope ('by time'), but does not explicitly differentiate it from sibling tools like 'get_balances_v4' or 'get_wallet_balances_v4', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'To get started, provide a chain name, comma-separated list of addresses and specify one of the filters listed below (combination of the filters is not allowed).' It includes specific prerequisites and constraints (e.g., no filter combinations), but does not explicitly mention when to use this tool versus alternatives like 'get_balances_v4' or 'get_wallet_balances_v4'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a fee estimation tool ('2 credits per API call'), returns gas price in wei, and requires conversion to Gwei for transactions. However, it doesn't cover error handling, rate limits, or authentication needs, leaving some gaps.
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 front-loaded with the core purpose, followed by a critical note on unit conversion. Both sentences are essential—the first defines the tool, and the second prevents user error. It's appropriately sized with no redundant information.
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 no annotations and no output schema, the description covers the basic purpose and a key behavioral note (unit conversion), but it lacks details on return format, error cases, or broader context (e.g., what '2 credits' means). For a tool with zero parameters, this is adequate but not fully comprehensive.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on output semantics (gas price in wei, conversion to Gwei) rather than inputs, earning a baseline score of 4 for not adding unnecessary param info.
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's purpose: 'Get an estimated gas price and the number of gas units needed for a Harmony transaction.' It specifies the verb ('Get') and resource ('estimated gas price and gas units'), though it doesn't explicitly differentiate from siblings like 'eth_estimate_gas' or 'bsc_estimate_gas' beyond mentioning 'Harmony transaction'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Harmony transactions and provides a note on converting wei to Gwei, but it lacks explicit guidance on when to use this tool versus alternatives (e.g., compared to other blockchain-specific gas estimation tools in the sibling list). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it mentions the API cost ('50 credit per API call'), response behavior ('return true if provided wallet address owns them... false and status code is 200'), and supports checking specific NFTs with tokenId. However, it lacks details on error handling, rate limits, or authentication needs, which are common for API tools.
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 somewhat front-loaded with the core purpose, but it includes extraneous information like the note for v3 API users and a detailed list of blockchains that could be summarized. Sentences like 'It is also possible to check if wallet address owns a specific NFT by specifying a tokenId' are useful but could be integrated more efficiently. Overall, it's informative but not optimally concise.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose, usage, and some behavioral aspects but lacks details on output format beyond true/false, error cases, or integration with sibling tools. Without an output schema, more explanation of return values would be beneficial, but the description does provide enough context for basic use.
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 description coverage is 100%, so the baseline is 3. The description adds some value by explaining that tokenAddress can be for 'any fungible token, NFT or multitoken collection' and that tokenId is for 'a specific NFT token,' but it doesn't provide additional syntax, format, or constraints beyond what's in the schema descriptions. It also lists supported chain values, which helps but doesn't fully compensate for the schema's already comprehensive coverage.
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 tool's purpose: 'Check if wallet address owns any specified token (ERC-20, ERC-721 or ERC-1155) on the following blockchains...' It specifies the exact action (check ownership), resources (tokens on specific blockchains), and distinguishes it from sibling tools like get_balances_v4 or get_owners_v4 by focusing on ownership verification of specific tokens rather than retrieving balances or owners.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to verify token ownership for specific blockchains, token types, and addresses. It mentions prerequisites ('To get started: Provide a chain name, wallet address and address of any fungible token...') but does not explicitly state when NOT to use it or name alternatives among sibling tools, though the specificity implies alternatives like get_balances_v4 for broader balance checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates several important behavioral traits: the tool is deprecated (important lifecycle information), it costs '50 credits per API call' (resource consumption), it supports multiple blockchains and token types, it includes metadata in responses by default (with option to exclude), and it has specific limitations for Tezos blockchain. It doesn't mention rate limits, error handling, or authentication requirements, but covers substantial behavioral context.
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 front-loaded with critical information (deprecation notice and alternative), but becomes somewhat verbose in listing all supported blockchains. The technical details about Tezos behavior and query parameter limitations could be more streamlined. While most content is relevant, the structure could be improved for better scannability, and some redundancy exists in the blockchain listing.
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?
Given the tool's complexity (6 parameters, multiple blockchain support, deprecation status) and absence of both annotations and output schema, the description provides substantial context. It covers purpose, deprecation status, supported networks, token types, basic usage, and some behavioral traits. The main gap is the lack of information about response format or structure, which would be important since there's no output schema. However, it compensates well with practical implementation guidance.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some semantic context: it explains that addresses should be 'comma-separated' and mentions the 'excludeMetadata' parameter's effect. However, it doesn't provide significant additional meaning beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does most of the parameter documentation work.
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's purpose: 'Get balances of fungible tokens (ERC-20), NFTs (ERC-721 and ERC-1155) or multitokens (ERC-1155 only) for a specific wallet address on the following blockchains...' It specifies the verb ('Get'), resource ('balances'), and scope (multiple blockchain networks and token types). However, it doesn't explicitly differentiate from sibling tools like 'get_wallet_balances_v4' or 'get_wallet_portfolio_v4' beyond mentioning the latter as a replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states this endpoint is deprecated and recommends migrating to 'GET /v4/data/wallet/portfolio' as a faster, more reliable alternative. It specifies the deprecation timeline (End of Life on June 30, 2025) and includes a clear 'when-not-to-use' recommendation. The 'To get started' section also provides practical implementation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: cost (50 credits per API call), supported token types and blockchains, pagination capability (implied through offset/pageSize), and metadata exclusion option. It doesn't mention rate limits, error handling, or authentication requirements, but covers most operational aspects well for a read-only tool.
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 information-dense but somewhat disorganized, mixing API endpoint details, credit cost, blockchain lists, usage instructions, and parameter notes in a single paragraph. While all content is relevant, better structuring (e.g., separating usage instructions from parameter details) would improve readability. It's not excessively verbose but could be more elegantly organized.
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 tool with 6 parameters, no annotations, and no output schema, the description provides substantial context: it explains what the tool returns (portfolio balances with token information), lists supported blockchains, mentions pagination and metadata options, and specifies required parameters. The main gap is lack of output format details, but given the tool's complexity, the description covers most essential aspects well.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context about tokenTypes ('Supported values include [native], [fungible] and [nft,multitoken]') and mentions excludeMetadata's effect, but doesn't provide significant additional parameter semantics beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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 tool's purpose: 'Get portfolio balances of native, fungible tokens (ERC-20) or NFTs (ERC-721 and ERC-1155) for a specific wallet address' on listed blockchains. It specifies the exact resource (wallet portfolio), verb (get balances), and distinguishes from siblings like get_balances_v4 or get_nft_balances_v4 by covering multiple token types in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'To get started: Provide a chain name and an address of that chain.' It mentions the API cost (50 credits per call) and lists supported blockchains. However, it doesn't explicitly state when to use alternatives like get_balances_v4 or get_nft_balances_v4, which might be more specialized tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses the API cost (10 credits per call), explains the gas price calculation methodology (from multiple sources, latest N blocks, mempool state), specifies default behavior (fast gas price), and notes the return unit (wei) with conversion requirement. It doesn't mention error conditions or rate limits, but covers key behavioral aspects.
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 appropriately sized (3 sentences) and front-loaded with the core purpose. The note about unit conversion is essential but could be slightly more concise. Every sentence adds value, with no redundant information.
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 tool with no annotations, no output schema, and one well-documented parameter, the description provides good context: purpose, usage guidance, behavioral details (cost, calculation method, defaults), and critical conversion note. It doesn't describe the output format (though hinted via 'estimated gas price' and 'number of gas units'), which is a minor gap given no output schema.
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 description coverage is 100% (the single parameter 'x-testnet-type' is fully documented in the schema with description and enum). The description doesn't add any parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage. Baseline 3 is appropriate.
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 specific action ('Get an estimated gas price and the number of gas units needed for an Ethereum transaction'), identifies the resource (Ethereum transaction), and distinguishes it from siblings by specifying Ethereum (vs. BSC, Celo, etc. in sibling tools). It goes beyond the tool name to explain what the estimation includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for Ethereum transaction fee estimation) and includes a critical note about converting wei to Gwei for actual transactions. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings (e.g., eth_estimate_gas_batch for batch operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read operation (implied by 'Get balances'), discloses the cost ('50 credits per API call'), mentions deprecation status and timeline, lists supported blockchains, explains response content (balances with metadata unless excluded), and notes parameter limitations (e.g., 'Following query parameters won't have any effect on filtering data excludeMetadata'). However, it doesn't cover rate limits, authentication needs, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and poorly structured. It mixes deprecation warnings, usage notes, parameter explanations, and blockchain lists in a dense paragraph. Key information (like the deprecation) is buried, and sentences like 'Following query parameters won't have any effect on filtering data excludeMetadata' are confusing. It could be significantly streamlined for better readability.
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?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description does a reasonably complete job. It covers the purpose, deprecation context, supported blockchains, basic usage, response content, and some parameter behaviors. However, it lacks details on output format (e.g., what the balance data looks like), pagination behavior (though offset and pageSize are in schema), and error cases, which would be helpful for an agent.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context by mentioning 'comma-separated list of addresses' (redundant with schema), 'excludeMetadata to true' (redundant), and token type filtering options (partially redundant with schema's enum description). It provides minimal additional semantic value beyond what's in the schema, meeting the baseline for high coverage.
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 tool's purpose: 'Get balances of native, fungible tokens (ERC-20), NFTs (ERC-721 and ERC-1155) or multitokens (ERC-1155 only) for a specific wallet address on the following blockchains...' It specifies the exact resource (wallet balances), the types of tokens included, and distinguishes it from the newer sibling tool 'get_wallet_portfolio_v4' by explicitly mentioning the deprecation and recommending migration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it states that the endpoint is deprecated, recommends migrating to 'GET /v4/data/wallet/portfolio' (which corresponds to sibling tool 'get_wallet_portfolio_v4'), and gives an end-of-life date. It also explains when to use it ('To get started: Provide a chain name and comma-separated list of addresses') and mentions limitations like the Tezos-specific behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a fee estimation tool (not a transaction execution), specifies the data source (bitquery.io), notes the cost (2 credits per API call), and warns about unit conversion (peb to Gpeb). This adds valuable context beyond basic functionality.
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 front-loaded with the core purpose, followed by important details (cost, source, conversion note). It uses three sentences efficiently, with each adding value (estimation details, credit cost, conversion warning). Minor room for improvement in flow, but overall well-structured and concise.
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?
Given no annotations, no output schema, and 0 parameters, the description provides good completeness: it explains what the tool does, its cost, data source, and critical conversion requirement. It could slightly enhance by mentioning output format or error cases, but covers essential context for a fee estimation tool.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose and behavior. A baseline of 4 is applied as it compensates well for the lack of parameters by explaining other aspects.
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 specific action ('Get an estimated gas price and the number of gas units') for a specific resource ('Klaytn transaction'), distinguishing it from siblings like 'eth_estimate_gas' or 'bsc_estimate_gas' by specifying the blockchain. It goes beyond just restating the name by detailing what the estimation includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context for Klaytn transactions and mentions a conversion requirement for submitting transactions, but does not explicitly state when to use this tool versus alternatives (e.g., other blockchain-specific gas estimators in the sibling list). It provides some guidance but lacks explicit comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: the tool estimates gas price from multiple sources based on latest blocks and mempool state, uses fast gas price by default, returns results in the same order as input, and notes the credit cost (10 per API call + 10 per estimation). It also warns about unit conversion (wei vs. Gwei) for practical use.
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 appropriately sized but could be more front-loaded; it starts with credit cost details before stating the core purpose. Sentences earn their place by covering cost, functionality, behavior, and warnings, but the structure slightly buries the main action, reducing immediate clarity.
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?
Given the complexity of batch gas estimation with no annotations or output schema, the description is largely complete. It covers purpose, usage context, behavioral details (sources, ordering, defaults), and critical warnings (unit conversion). However, it lacks explicit error handling or rate limit information, which could enhance completeness for this type of tool.
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?
The input schema has 100% description coverage for its single parameter ('x-testnet-type'), so the baseline is 3. The description adds value by implicitly clarifying that transactions are submitted in the request (though not detailing the parameter structure) and emphasizing the batch nature, which compensates beyond the schema's basic enum documentation.
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 tool's purpose with specific verbs ('Get an estimated gas price and the number of gas units needed') and resources ('for multiple Ethereum transactions'), distinguishing it from siblings like 'eth_estimate_gas' by emphasizing batch processing. It explicitly mentions the scope of fee estimation and ordering of results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for estimating gas for multiple Ethereum transactions) and includes a practical note about unit conversion for transaction submission. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'eth_estimate_gas' for single transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a read-only operation (implied by 'Get an estimated'), mentions a cost ('2 credits per API call'), specifies the data source, and provides critical behavioral notes about unit conversion (wei to Gwei) for transaction submission. This adds substantial context beyond basic functionality.
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 appropriately sized and front-loaded, starting with the core purpose and cost, followed by essential behavioral details. Every sentence earns its place: the first defines the tool, the second specifies the data source, and the third provides critical usage guidance. There is no wasted text, making it highly efficient.
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?
Given the tool's complexity (fee estimation with unit conversion), no annotations, no output schema, and 0 parameters, the description is largely complete. It covers purpose, cost, data source, and key behavioral notes. However, it lacks details on error handling, rate limits, or example outputs, which could enhance completeness for an AI agent.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description compensates by explaining the output semantics: it returns estimated gas price (in wei) and gas units, and includes a crucial note about converting to Gwei for transactions. This adds meaningful value beyond the empty schema.
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 tool's purpose with specific verbs ('Get an estimated gas price and the number of gas units') and resources ('for a BNB Smart Chain transaction'), distinguishing it from sibling tools like 'eth_estimate_gas' or 'celo_estimate_gas' by specifying the BNB Smart Chain context. It explicitly mentions the source of gas price data (explorer.bitquery.io/bsc/gas), further differentiating its functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for estimating gas on BNB Smart Chain transactions, with an implicit alternative being other blockchain-specific tools (e.g., 'eth_estimate_gas' for Ethereum). However, it does not explicitly state when not to use it or compare it directly to all sibling tools, such as 'estimate_fee_blockchain' or 'get_blockchain_fee', which might offer broader fee estimation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: the data source (https://explorer.bitquery.io/celo_rc1/gas), cost implications (2 credits per API call), and critical usage details (gas price returned in wei, must convert to Gwei for transactions). No contradictions exist.
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 front-loaded with the core purpose, followed by essential details in a logical flow. Every sentence adds value: the first states the action and cost, the second specifies the data source, and the third provides critical usage notes. It is efficiently structured with zero waste.
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?
Given the tool's complexity (gas estimation with unit conversion), no annotations, and no output schema, the description is largely complete. It covers purpose, cost, data source, and key behavioral notes. A minor gap is the lack of explicit output format details, but the focus on gas price and units suffices for clarity.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on operational semantics (e.g., gas estimation process and unit conversion) without redundant parameter details, exceeding the baseline of 3 by adding valuable context beyond the schema.
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 specific action ('Get an estimated gas price and the number of gas units') and resource ('for a Celo transaction'), distinguishing it from sibling tools like 'eth_estimate_gas' by specifying the Celo blockchain context. It uses precise verbs and identifies the exact scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (estimating gas for Celo transactions) and includes a practical note about converting wei to Gwei for transaction submission. However, it does not explicitly mention when not to use it or name specific alternatives among siblings, such as 'eth_estimate_gas' for Ethereum transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![blockchain-mcp MCP server](https://glama.ai/mcp/servers/tatumio/blockchain-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tatumio/blockchain-mcp)

Score Badge

Copy to your README.md:

[![blockchain-mcp MCP server](https://glama.ai/mcp/servers/tatumio/blockchain-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tatumio/blockchain-mcp)

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/tatumio/blockchain-mcp'

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