GoldRush MCP Server

Server Quality Checklist

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

Latest release: v0.0.4
Disambiguation3/5
Several tools have overlapping purposes, e.g., various balance tools (token_balances, historical_token_balances, multichain_balances, native_token_balance) and multiple transaction tools (transaction, transactions_for_address, bitcoin_transactions). While descriptions clarify parameters, an agent could easily misselect the wrong tool for a given task.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern with descriptive verb_noun structure. Minor deviations include 'for' prepositions (e.g., transactions_for_address, nft_for_address) but overall naming is predictable and clear.
Tool Count3/5
27 tools exceeds the typical well-scoped range (3-15). While the server covers a broad domain (Bitcoin, EVM, NFTs, tokens, blocks, etc.), the count feels heavy and may overwhelm agents. Some consolidation could improve efficiency.
Completeness4/5
The tool surface is comprehensive for a read-only blockchain data API, covering balances, transactions, blocks, tokens, NFTs, gas, pools, historical data, and approvals. Missing operations like token price current or write actions are intentional due to the server's purpose, but minor gaps exist (e.g., no dedicated current price endpoint).
Average 3.8/5 across 27 of 27 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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.
Add a glama.json file to provide metadata about your server.
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?
No annotations provided, so the description should disclose behavioral traits. It mentions return type (ownership status and matching NFTs) but omits details like read-only nature, pagination, rate limits, or side effects.
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 two concise sentences front-loading the purpose, then listing parameters. No wasted words, though additional structure could enhance 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?
For a simple read tool with 5 params and full schema coverage, the description is adequate. It lacks output schema details and sibling differentiation, but overall covers the essential 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%, and the description adds no new parameter meaning beyond summarizing required/optional. The description is helpful but not necessary beyond the schema.
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 verifies ownership of NFTs (ERC-721 and ERC-1155) within a collection. It lists required and optional parameters, and the scope is implicit but distinct from sibling nft_check_ownership_token_id.
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 checking collection-level ownership but does not explicitly differentiate from alternatives like nft_check_ownership_token_id or nft_for_address. No when-not or prerequisites are stated.
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, the description carries the full burden. It discloses pagination behavior and inclusion of decoded log events, but lacks details like error handling, response format, or authentication requirements. Adequate but not thorough.
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 (two sentences) and front-loaded with the core purpose. The second sentence listing parameters is somewhat redundant with the schema, but overall it is structured efficiently.
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 output schema and 6 parameters, the description covers the basic functionality but misses details like default values (e.g., noLogs defaults to true), page size limits, and error cases. Sufficient for a simple use case but not fully complete.
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?
All parameters have schema descriptions (100% coverage), so the description's parameter summary adds little new information beyond listing with parentheticals. It confirms the required/optional split but does not enhance understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches transactions for an address with decoded log events in a paginated manner, using a specific verb+resource combination. While it doesn't explicitly distinguish from siblings like 'transactions_for_block' or 'log_events_by_address', the mention of 'decoded log events' provides some differentiation.
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 only says 'commonly used' without specifying when to use this tool versus alternatives. No guidance on when not to use it or which sibling tools might be better suited for different contexts is provided.
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 the return type (time series data) but does not disclose any other behavioral traits such as pagination, rate limits, data freshness, or that it is a read-only operation. For a tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, fitting into a single sentence plus a brief list. It is front-loaded with the core purpose and then enumerates parameters efficiently. However, it could be slightly more structured by separating parameter details from the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, two with enums, and no output schema. The description mentions it returns time series data but does not explain the structure of the output (e.g., fields like date, value, token). Given the complexity, the description is incomplete for an agent to understand the full response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes parameters well. The description adds minimal value beyond the schema, only restating required fields and the default for days. It provides no additional context for parameter values or constraints.
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 renders a daily portfolio balance for an address broken down by token. The verb 'render' and resource 'portfolio balance' are specific, and it distinguishes itself from sibling tools like historical_token_balances by focusing on portfolio value.
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 lists required and optional parameters, which provides basic usage guidance. However, it does not explicitly explain when to use this tool versus alternatives like historical_token_balances or historical_token_prices, nor does it mention constraints or prerequisites.
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 must fully disclose behavioral traits. It mentions token support and domain resolution but omits rate limits, error handling, response format, and whether multiple tokens are supported (ambiguity from 'one (or many)').
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 with a clear separation of required and optional parameters. It is front-loaded with purpose. Could be slightly more structured for 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?
Given no output schema, the description should detail return format but only says 'Returns historical token prices'. The ambiguity around 'one (or many)' tokens and lack of pagination or error handling leaves significant 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 coverage is 100%, so the baseline is 3. The description adds context (native token support, default sort order) but largely reiterates schema descriptions without significant additional meaning.
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 retrieves historical prices for ERC20 and native tokens within date ranges, using specific verbs 'Get' and 'supports'. It distinguishes from siblings like 'historical_token_balances' by focusing on prices.
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 lists required and optional parameters but does not explicitly state when to use this tool versus alternatives like 'historical_token_balances' or 'pool_spot_prices'. Usage context is implied but not formally contrasted.
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 behavioral burden. It discloses that the tool returns decoded event logs and requires a contract address and chain, but lacks details on side effects, rate limits, or data freshness.
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 dense with two long sentences; it could be more structured (e.g., bullet points). It is not overly verbose, but lacks ideal conciseness.
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?
The tool has 6 parameters, no output schema, and moderate complexity. The description covers the core purpose and parameters but omits details on pagination behavior or error handling.
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% coverage, and the description restates key parameters. It adds value by mentioning ENS resolution for contractAddress but does not provide additional meaning beyond the schema.
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 retrieves event logs from a specific contract address and is used for dashboards and monitoring. However, it does not explicitly differentiate from sibling tool 'log_events_by_topic'.
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 explains typical use cases and lists required and optional parameters, but does not specify when to avoid this tool or suggest alternatives.
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 provided, so description carries full burden. It only mentions 'lightweight' and return content, but fails to disclose behavioral traits like read-only nature, error conditions, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and key parameters. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-balance tool with full schema coverage and no output schema, description covers purpose, parameters, and return value. Missing minor details like response format or error handling, but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Description adds minimal value by summarizing the parameters and adding return context (market value, metadata). 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?
Description clearly states it returns native token balance for an EVM address, using specific verb 'get'. Distinguishes from sibling balance tools like 'erc20_token_transfers' and 'token_balances' by specifying 'native token', but does not explicitly differentiate from all siblings.
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?
Description lists required and optional parameters, implying when to use (quick native token balance check). However, it does not provide explicit guidance on when not to use or suggest alternatives among siblings.
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, and the description only covers basic usage without disclosing behaviors such as error handling, rate limits, or idempotency. It is minimally adequate 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 concise but contains filler phrasing ('Commonly used') and could be more direct. The parameter listing is redundant given the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the return structure (e.g., fields in summary) and does not compensate for the missing output schema, leaving the agent guessing about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description reiterates parameter names without adding significant new meaning beyond the schema defaults. The mention of withGas including gas stats adds marginal value.
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 fetches the earliest and latest transactions and transaction count for a wallet, distinguishing it from sibling tools like transactions_for_address that fetch full lists.
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 lists required and optional parameters but provides no guidance on when to use this tool versus alternatives like transaction or transactions_for_address.
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 optional parameters that affect behavior (filtering spam, excluding metadata, uncached fetching) and notes it returns 'complete details including metadata'. However, it does not specify pagination, data limits, or potential performance implications for wallets with many NFTs.
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: two sentences. The first sentence clearly states the purpose, and the second lists parameters and return. Every word earns its place, and the key information is front-loaded.
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 output schema and 5 parameters, the description covers the main function and parameter effects. However, it lacks details on return structure (e.g., format of NFT details), pagination, and any limits on result size. This leaves some ambiguity for an agent needing to use the output 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 coverage is 100%, so the baseline is 3. The description restates required and optional parameters similarly to the schema descriptions, adding only the note that walletAddress can be ENS/domain and that return includes metadata. It does not provide deeper semantics beyond what the schema already conveys.
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 explicitly states the tool retrieves NFTs (ERC721/ERC1155) held by an address, with a specific verb 'render' and resource 'NFTs'. It clearly distinguishes from sibling tools like nft_check_ownership by focusing on all NFTs for an address rather than ownership checks for specific tokens.
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 does not provide guidance on when to use this tool versus alternatives. It only lists required and optional parameters without explaining scenarios where nft_check_ownership or nft_check_ownership_token_id would be more appropriate. No explicit exclusions or context for selection among siblings.
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 provided, so description carries full burden. It describes return values (timestamps, amounts, transaction IDs) and pagination behavior. It implies a read-only operation, but does not explicitly state that it is non-destructive or any side effects.
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?
Description is concise and well-structured: a clear opening sentence, followed by parameter descriptions and return value summary. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return values adequately. It addresses pagination and key parameter details. Lacks mention of error handling or edge cases, but overall sufficient for a straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description restates some schema info (required address, optional pageSize/pageNumber with defaults) and adds context about output, but does not significantly enhance parameter understanding beyond schema.
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?
Clear verb and resource: 'fetch the full transaction history of a Bitcoin wallet.' However, with many sibling transaction tools (e.g., transactions_for_address, multichain_transactions), the description does not differentiate this tool from similar ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While it lists required and optional parameters, it does not explain in what contexts this tool is preferred over siblings like transactions_for_address.
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 present, so the description bears full burden. It mentions pagination defaults and queries across contracts, but does not disclose rate limits, authentication needs, or behavior on invalid parameters.
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 with purpose and usage, then lists parameters. It is efficient with no fluff, though could be more structured with bullet points.
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?
No output schema is provided, and while required and optional parameters are explained, the return format is only briefly mentioned as 'decoded event logs.' Additional details on pagination behavior or block range limits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with solid parameter descriptions. The description adds context (e.g., block range, secondaryTopics) but does not significantly augment the schema details.
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 retrieves event logs by topic hash across all contracts on a given chain, distinguishing it from similar tools like log_events_by_address which filter by address.
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 indicates it is 'commonly used' for cross-sectional analysis but does not explicitly state when to use alternatives like log_events_by_address or provide exclusions.
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 must fully inform about behavior. It mentions that log events are included by default and can be excluded via noLogs, but it omits details about pagination, rate limits, or the exact return format. The page parameter is required but not mentioned, which is a behavioral gap.
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 short at two sentences, which is efficient, but the omission of the page parameter and lack of structure (no bullet points or section separation) reduce clarity. It could be more complete without extra length.
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 5 parameters and no output schema, the description covers the main purpose and some options but fails to mention the required page parameter or clarify the output structure. For a tool that fetches all transactions from a block, additional context like pagination behavior and output fields would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description incorrectly states that only chainName and blockHeight are required, while the schema also requires 'page'. This omission misleads about parameter semantics and reduces the value 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 verb 'fetch' and resource 'transactions including decoded log events in a block', and gives a specific use case (flag interesting wallets or transactions). It distinguishes from siblings like transaction (single tx) or transactions_for_address (by address) by focusing on block-level retrieval.
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 a common use case and lists required and optional parameters, implying when to use. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, which would strengthen guidance.
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 describes the return summary (transaction counts, timestamps, status) and implies a read-only analysis, but does not explicitly state behavioral traits like safety, permissions, or side effects. It is adequate but not comprehensive.
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 highly concise with three sentences: first states purpose, second details parameters, third summarizes returns. Every sentence is essential and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, no output schema, and no annotations, the description covers purpose, parameters with resolution details, and return summary. It is complete enough for a straightforward tool but could mention error handling or edge cases (e.g., invalid address).
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 already has 100% description coverage, but the description adds valuable context: walletAddress can accept ENS, RNS, Lens Handle, or Unstoppable Domains with automatic resolution. It also clarifies the testnets default and effect. This goes beyond schema, justifying a 4.
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: to locate chains an address is active on with a single API call. It specifies the required walletAddress and optional testnets. While it doesn't explicitly distinguish from sibling tools like multichain_balances or multichain_transactions, the unique focus on activity (transaction counts, timestamps, status) is evident.
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 context ('Commonly used to locate chains') and notes the single-call efficiency, but lacks explicit guidance on when not to use or alternatives. It does not mention scenarios where this tool is inappropriate or suggest other tools for different needs.
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 bears full responsibility. It only says 'Returns ownership status' but does not disclose whether the operation is read-only, has side effects, or any constraints like rate limits. This is minimal transparency.
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?
Four concise sentences: one states purpose, one lists required parameters, and one describes output. No wasted words; front-loaded with use case.
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?
No output schema exists, but the description only says 'Returns ownership status' without detailing the format (e.g., boolean, object). With 4 required params and no output schema, a bit more information about the return value would improve completeness.
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 baseline is 3. The description merely restates parameter names and uses without adding substantial meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'verify ownership of a specific token (ERC-721 or ERC-1155) within a collection,' using a specific verb and resource. It distinguishes from sibling 'nft_check_ownership' by specifying token ID.
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?
Provides clear context for when to use (verify ownership of specific token) and lists all required parameters. However, it does not mention alternatives or exclusions, such as when to use the sibling tool 'nft_check_ownership'.
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 exist, so the description bears full burden. It mentions optional parameters to control NFT fetching and spam filtering, and states returns include spot prices and metadata. However, it lacks details on side effects, performance impact, or pagination.
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?
Three sentences, front-loaded with purpose, no fluff. Each sentence adds distinct value: purpose, required/optional, and return type. Ideal conciseness.
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 7 parameters and no output schema, the description covers basics but lacks details on error handling, pagination, or performance considerations. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds grouping and default values for boolean parameters, but this is marginal extra value beyond the schema. 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 tool fetches native and ERC20 tokens for an address on a specific chain, with optional NFTs. It uses a specific verb 'fetch' and resource 'tokens held by an address', distinguishing it from siblings like 'native_token_balance' or 'token_holders'.
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 required and optional parameters but offers no guidance on when to use this tool versus siblings (e.g., for current vs historical balances, single chain vs multichain). Usage is implied but not explicitly scoped.
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?
The description discloses that the response includes spot prices, metadata, total balance, available balance, and transaction count. However, it does not explain the meaning of 'non-HD' nor any potential limitations or prerequisites beyond the required parameter.
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 clear but slightly verbose with five sentences. It could be more streamlined without losing essential 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?
Lacking an output schema, the description provides some return field details but does not fully specify the structure or clarify key concepts like 'non-HD', leaving some uncertainty 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 coverage is 100% and the description largely reiterates the schema's information (required vs optional, enum values). It adds minimal new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches Bitcoin balance for a non-HD address, using specific verbs and resource, and distinguishes from sibling 'bitcoin_hd_wallet_balances' by specifying 'non-HD'.
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 non-HD addresses by naming the tool accordingly, but does not explicitly contrast with alternatives or provide when-to-use guidance for the sibling 'bitcoin_hd_wallet_balances'.
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, the description carries full burden. It discloses output fields (timestamp, transaction count, etc.) but omits behavioral traits such as error handling, rate limits, or authentication needs. Adequate but not comprehensive.
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 two concise sentences, front-loaded with the main purpose and key parameters. No redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers purpose, required inputs, and key output fields. Lacks error handling or edge cases, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description's parameter info barely adds value beyond the schema. It mentions blockHeight can be 'latest', but that's already in schema. 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 action (fetch and render), resource (single block), and context (block explorer). It distinguishes from siblings like 'transactions_for_block' and 'block_heights' by focusing on comprehensive block data retrieval.
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 block data retrieval but lacks explicit guidance on when to use this tool vs alternatives like 'block_heights' or 'transactions_for_block'. No exclusion criteria or when-not-to-use advice is provided.
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 states the tool fetches balances and returns details like total balance, but does not disclose authentication, rate limits, or side effects. It is adequate for a simple read operation.
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 relatively short with three sentences plus a parameter list. It front-loads the purpose. Some redundancy exists (return details restated), but overall it is 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 the tool's simplicity (2 parameters, no output schema), the description covers purpose, inputs, and output summary sufficiently. It mentions transaction history summary, which adds useful 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%, and the description essentially repeats the parameter info. It adds no new meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches balances for each active child address derived from a Bitcoin HD wallet, specifying the resource and action. It distinguishes from sibling tool 'bitcoin_non_hd_wallet_balances' by explicitly mentioning HD wallet and xpub key.
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 clearly lists required and optional parameters, providing context on when to use the tool. However, it does not explicitly contrast with alternatives like 'bitcoin_non_hd_wallet_balances' or state when not to use it.
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 provided, so the description carries full burden. It transparently indicates the tool is a read-only query returning transfer events, with no side effects or destructive actions mentioned.
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 well-structured with main purpose first, then parameter details. At 2-3 sentences it is appropriately sized, though some redundancy with schema exists.
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 output schema, the description adequately describes return types (timestamps, values, transaction details). With 100% param coverage, it is complete for its complexity.
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?
Input schema has 100% coverage with descriptions; the description adds default values for pageSize and pageNumber and mentions the return format, but does not significantly extend 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 it retrieves 'transfer-in and transfer-out of a token along with historical prices from an address,' using specific verbs and resources. This distinguishes it from sibling tools like token_balances or transactions_for_address.
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 lists required and optional parameters, implying when to use, but does not explicitly state when not to use or compare with alternatives like log_events_by_address or historical_token_balances.
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, the description carries full behavioral burden. It clarifies required parameters, pagination defaults, and return data (block heights, timestamps). Does not disclose rate limits or authentication, but the read-only nature is implied and no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, parameters, and returns. No unnecessary words, front-loaded with the common use case. Every sentence adds value.
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?
Describes return data as 'block heights, timestamps, and related data' which is slightly vague but adequate. Lacks output schema, but the description covers key aspects. Pagination and required parameters are clear.
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 baseline is 3. Description restates schema details (format, defaults) without adding new meaning beyond what is already in 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?
Description states 'get all the block heights within a particular date range', specifying the verb (get), resource (block heights), and scope (date range). It clearly distinguishes from sibling tools like 'block' which retrieves a single block.
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?
Description implies usage for historical analysis and time-based queries but does not explicitly state when not to use or mention alternatives like 'block' or 'transactions_for_block'. Provides some context but lacks direct 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, the description carries full responsibility for behavioral disclosure. It reveals that the tool is read-only, returns estimates for low/medium/high priority, and supports currency conversion. It does not cover rate limits or error behavior, but for a simple read tool this is adequate.
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 at three sentences, front-loading the main purpose. It avoids redundancy and unnecessary detail. A slight improvement could be breaking into bullet points, but it remains highly readable.
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 output schema and no annotations, the description adequately covers the input parameters, the return type (low, medium, high estimates), and optional currency conversion. It lacks details on unit or error handling, but for a straightforward gas price tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all parameters. The description adds context by explaining the meaning of eventType options and the conversion purpose of quoteCurrency, but does not provide significant new information beyond the schema. Baseline of 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 verb ('get'), resource ('real-time gas estimates'), and context ('for different transaction speeds on a specific network'). It effectively distinguishes from sibling tools that focus on balances, transactions, or NFTs, as no other sibling provides gas price estimates.
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 explicitly lists required parameters (chainName, eventType) and explains their role, as well as the optional quoteCurrency. It provides enough context for when to use the tool, though it does not explicitly mention alternatives or when not to use it. However, the sibling set does not overlap in functionality, making this less critical.
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 provided, so description carries full burden. It discloses defaults for boolean flags and states it returns balances as they existed historically. Does not describe output format or rate limits, but for a read operation, it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence that lacks clear structure. While it front-loads the core purpose, the parameter listing feels cluttered and could be broken into cleaner segments for better 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 the complexity (9 parameters, no output schema), the description covers parameter usage well but omits return structure, pagination, or limits. This leaves the agent partially informed about the response format.
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?
Schema coverage is 100%, but the description adds value by summarizing required vs optional, listing parameter names, highlighting defaults, and noting mutual exclusivity of blockHeight and date. This goes beyond the schema alone.
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 fetches historical token balances for an address at a given block height or date. It explicitly mentions the required and optional parameters, distinguishing it from current balance tools like 'token_balances'.
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 implies historical vs current context through name and parameter hints, and explicitly notes mutual exclusivity of blockHeight and date. However, it does not directly compare to sibling tools or state when not to use this tool.
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, the description carries the full burden for behavioral disclosure. It mentions pagination, defaults, and optional logs inclusion, but lacks details on error handling for exceeding address/chain limits, rate limits, or data freshness. The description is adequate but not comprehensive.
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 concise with three sentences, front-loading the main action and purpose. Every sentence provides essential information without redundancy or filler, making it easy to scan.
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 lack of an output schema, the description does not explain what the response contains (e.g., transaction fields, pagination cursors). With 8 parameters and no annotations, the description covers core functionality but leaves gaps about return values and edge cases, making it somewhat incomplete.
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?
Although parameter descriptions in the schema are complete (100% coverage), the tool description adds value by summarizing key optional parameters, clarifying limits (up to 10 addresses/chains) and the requirement of the addresses array (though the schema marks it optional, which is a minor inconsistency). This extra context helps the agent understand usage beyond raw 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 fetches paginated transactions for up to 10 EVM addresses and 10 EVM chains in one call, which is specific and distinct from sibling tools like single-chain transaction fetchers. It also mentions use for building Activity Feeds, further clarifying its purpose.
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 indicates the tool is useful for analyzing transaction history across multiple networks and building activity feeds, providing clear context. However, it does not explicitly state when not to use it or contrast with alternatives like transactions_for_address or multichain_address_activity, so it misses some exclusion 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?
Without annotations, the description discloses the output (list of ERC20 approvals with risk levels) and implies a read-only operation. It does not detail side effects, pagination, or authentication needs, but the straightforward nature of the tool makes this adequate.
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 two sentences with front-loaded purpose, no wasted words. It efficiently conveys the tool's function, required inputs, and output.
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?
With no output schema, the description briefly mentions the return value as 'a list of ERC20 token approvals and their associated security risk levels'. This is informative but lacks structural details like fields or pagination, leaving some ambiguity for the 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?
Schema coverage is 100%, so the baseline is 3. The description provides examples for chainName and walletAddress, but these largely duplicate the schema descriptions. The mention of ENS support and alternative chain formats adds marginal value.
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 returns a list of token approvals across contracts, categorized by spenders, for a wallet's assets. It specifies the resource ('approvals') and the action ('get a list'), distinguishing it from sibling tools like token_balances or erc20_token_transfers.
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 lists required parameters with examples, providing clear context for use. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or exclusions. The lack of exclusions is acceptable given the tool's unique purpose.
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, description carries full burden. It implies read-only ('Fetch') and mentions pagination, but lacks details on data freshness, rate limits, or side effects. Adequate but not thorough.
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?
Three well-structured sentences: purpose, parameter list, use case. No fluff, every sentence adds value.
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?
Covers main functionality with 6 parameters described. Missing response structure details, but given no output schema, the description provides sufficient context for the agent to use it.
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?
Schema coverage is 100%, but the description adds value by explaining each parameter's role in context, such as cutoffTimestamp for filtering by time and chains for network specification. Exceeds baseline.
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 fetches paginated spot and historical balances for a single address across up to 10 EVM chains, distinguishing it from single-chain siblings like token_balances and bitcoin_balances.
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?
It explicitly notes required walletAddress, optional parameters (chains, quoteCurrency, limit, before, cutoffTimestamp), and the use case for comprehensive cross-chain view. Slightly lacking explicit alternatives or when-not-to-use, but still clear 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?
No annotations are provided, so the description must convey behavioral traits. It indicates a read-only operation and describes the return content, but does not detail error handling, rate limits, or other side effects. This is adequate but not rich.
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 concise: four sentences covering purpose, supported protocols, required/optional parameters, and return values. No unnecessary words, each sentence earns its place.
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?
Although there is no output schema, the description adequately describes the return (spot prices with pool details and metadata). All parameters are documented. The tool's complexity is low, and the description provides sufficient context for an agent to use it correctly.
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 covers all parameters with descriptions (100% coverage). The description adds value by clarifying the purpose of quoteCurrency for value conversion and specifying supported DEX types, which goes beyond schema details.
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 retrieves spot token pair prices for a given pool contract address, specifying supported DEX types (Uniswap V2/V3 and forks). This uniquely distinguishes it from sibling tools which focus on balances, transactions, blocks, etc.
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 lists required and optional parameters and mentions supported protocols, providing clear context for when to use the tool. No explicit alternatives are needed as no sibling tool performs a similar function.
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. It discloses parameter defaults (e.g., noLogs defaults to true, withInternal defaults to false) and constraints (tracing only on eth-mainnet). However, it does not explicitly state that the tool is read-only, which is generally inferred but not guaranteed.
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 well-structured: a brief purpose statement, followed by a clear list of required and optional parameters, and a note on constraints. It is informative without being overly verbose, though it could be slightly more concise by combining sentences.
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?
While the description covers parameters well, it lacks details about the return value, stating only 'Returns comprehensive details about the specified transaction.' Since no output schema is provided, the description could better set expectations about what 'comprehensive details' includes, such as the structure of the response.
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 already has 100% coverage, but the description adds value by specifying default values for optional parameters (e.g., quoteCurrency defaults to USD) and highlighting that tracing features are only supported on eth-mainnet. This goes beyond the schema's descriptions, which lack some default context.
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: 'fetch and render a single transaction including its decoded log events.' It uses a specific verb ('fetch and render') and resource ('single transaction'), distinguishing it from sibling tools like 'transactions_for_address' which handle multiple transactions.
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 lists required and optional parameters, and notes that tracing features are only supported on eth-mainnet. While it does not explicitly state when not to use this tool versus alternatives, the context of 'single transaction' implies appropriate use cases compared to sibling tools for lists. The guidance is clear but not exhaustive.
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?
The description explains the tool returns a list of addresses with balances and ownership percentages, and mentions pagination and historical data. However, it does not explicitly state it is read-only or describe error handling, rate limits, or authentication requirements.
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 four sentences, front-loads the core purpose, and includes all critical information without unnecessary detail. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return format (list of addresses with balances and percentages) and covers all key parameters and their constraints. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema, but the description adds value by grouping required vs optional, noting mutual exclusivity of blockHeight and date, providing max pageSize, and mentioning ENS/RNS/Lens/UD resolution for tokenAddress.
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 gets a paginated list of current or historical token holders for ERC20 or ERC721 tokens. It specifies required and optional parameters, and distinguishes itself from sibling tools like token_balances by focusing on holders.
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 lists required and optional parameters, indicating when to use historical data features (blockHeight or date). However, it does not explicitly compare to sibling tools or specify when not to use this tool.
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:

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

Score Badge

Copy to your README.md:

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

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/covalenthq/goldrush-mcp-server'

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