Alchemy MCP Plugin

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_nfts_for_owner and get_contracts_for_owner, as well as between get_asset_transfers, get_transfers_for_contract, and get_transfers_for_owner, which could cause minor confusion. However, descriptions help clarify the specific focus of each tool.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores, such as get_block_number, estimate_gas_price, and lookup_address. There are no deviations in naming conventions, making the set highly predictable and readable.
Tool Count3/5
With 22 tools, the count is on the higher side for a blockchain-focused server, bordering on heavy but still manageable. It covers multiple aspects like NFTs, tokens, transactions, and events, but may feel slightly bloated compared to more streamlined sets.
Completeness5/5
The tool set provides comprehensive coverage for blockchain interactions, including data retrieval (blocks, transactions, NFTs, tokens), metadata access, transfers, ownership queries, and event subscriptions. There are no obvious gaps, and it supports full lifecycle operations for the domain.
Average 2.9/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, requires authentication, has rate limits, returns real-time or cached data, or error conditions. This is a significant gap for a tool with potential network implications.
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 with just three words, front-loaded with the core action ('Estimate current gas price'). There's no wasted text, and it efficiently conveys the essential purpose without unnecessary elaboration, making it highly structured 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 no annotations, no output schema, and a simple parameter, the description is incomplete. It lacks details on return values (e.g., gas price in Gwei, confidence intervals), behavioral traits, or error handling. For a tool that could impact transaction costs, more context is needed to ensure safe and effective use by 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 for its single parameter (maxFeePerGas), so the schema fully documents it. The description adds no parameter-specific information beyond implying gas price estimation, which aligns with the schema but doesn't provide extra semantic context. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Estimate current gas price' clearly states the tool's function with a specific verb ('estimate') and resource ('gas price'), but it doesn't differentiate from siblings. While siblings focus on NFTs, transfers, blocks, and addresses, this tool's purpose is distinct but not explicitly contrasted, making it clear but not sibling-aware.
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 (e.g., for Ethereum transactions), or compare to other gas-related tools (none in siblings), leaving the agent with no usage direction beyond the basic purpose.
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 retrieves transfers but doesn't describe key behaviors such as pagination handling (implied by 'pageKey' parameter), rate limits, authentication needs, or what the response format looks like. For a read operation with 10 parameters and no output schema, 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: 'Get asset transfers for a specific address or contract.' It's front-loaded with the core purpose and contains no wasted words, making it highly concise and well-structured 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 the complexity (10 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain the return format, pagination behavior, error conditions, or how parameters interact (e.g., filtering logic). For a tool that likely returns structured data, more context is needed to guide effective use, especially without annotations or output schema to fill in 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?
The input schema has 100% description coverage, so parameters like 'fromBlock' and 'category' are well-documented in the schema. The description adds minimal value beyond this, only implying filtering by address or contract without detailing parameter interactions or semantics. With high schema coverage, the baseline score of 3 is appropriate, as the description 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 asset transfers for a specific address or contract.' It uses a specific verb ('Get') and resource ('asset transfers'), and specifies the target ('address or contract'). However, it doesn't distinguish this tool from sibling tools like 'get_transfers_for_contract' or 'get_transfers_for_owner,' which appear to serve similar purposes, so it doesn't reach the highest 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 sibling tools like 'get_transfers_for_contract' or 'get_transfers_for_owner,' nor does it explain any prerequisites or exclusions. Usage is implied by the purpose but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but offers minimal information. It states what the tool does ('Get a block with its transactions') but doesn't describe behavioral traits such as whether it's a read-only operation, potential rate limits, error conditions, or what 'with its transactions' entails (e.g., full details vs. summaries). This leaves significant gaps for an agent to understand how to invoke it effectively.
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 front-loads the core functionality without any wasted words. It efficiently communicates the tool's purpose in a minimal format, 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 complexity of fetching blockchain data with transactions, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'with its transactions' means in terms of output (e.g., transaction objects, hashes, or details), nor does it cover error handling or behavioral aspects. This leaves the agent with insufficient context for reliable 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?
The input schema has 100% description coverage, with clear documentation for 'blockNumber' and 'blockHash', and the 'oneOf' constraint is structurally defined. The description adds no parameter-specific semantics beyond implying that either parameter can be used to fetch the block, which is already evident from the schema. This meets the baseline for high schema coverage but doesn't enhance 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 verb ('Get') and resource ('a block with its transactions'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_block_number' (which likely returns just the number) or 'get_transaction' (which focuses on individual transactions), missing an opportunity for precise 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. For example, it doesn't clarify if this should be used instead of 'get_block_number' when transaction details are needed, or how it relates to 'get_transaction' for individual transaction data. There's no mention of prerequisites, exclusions, or contextual usage.
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 but offers minimal behavioral insight. It implies a read-only operation ('Get') but doesn't disclose rate limits, authentication needs, error conditions, pagination behavior (beyond the pageKey/pageSize parameters), response format, or whether it's a real-time query. For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how it 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, front-loaded sentence with zero wasted words. It immediately conveys the core purpose without unnecessary elaboration. Every word earns its place, making it highly efficient for an AI 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 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address the tool's complexity (filtering, pagination), behavioral aspects, or return values. While concise, it fails to provide sufficient context for an agent to understand how to effectively use this tool beyond basic parameter passing. The lack of output schema means the description should ideally hint at response structure, which it doesn't.
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 fully documents all 5 parameters (owner, pageKey, pageSize, includeFilters, excludeFilters). The description adds no additional parameter semantics beyond the tool name implying the 'owner' parameter. It doesn't explain filter interactions (e.g., how include/exclude work together) or provide examples. With high schema coverage, the baseline 3 is appropriate as the description doesn't 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 verb 'Get' and resource 'NFT contracts owned by an address', making the purpose immediately understandable. It distinguishes from siblings like 'get_nfts_for_owner' (which retrieves NFTs rather than contracts) and 'get_nfts_for_contract' (which focuses on a specific contract). However, it doesn't explicitly mention the blockchain context or API source, which could be inferred but isn't stated.
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 (e.g., valid wallet address format), compare to siblings like 'get_nfts_for_owner' (for individual NFTs) or 'get_owners_for_nft' (reverse lookup), or specify use cases (e.g., portfolio analysis, contract discovery). The agent must infer usage from the 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, the description doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or what format the floor price is returned in. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core functionality and wastes no space on redundant information. This is an excellent example of efficient communication.
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 insufficiently complete. For a financial data retrieval tool, it should ideally specify whether this returns current or historical floor prices, what currency/units the price is in, whether authentication is required, and what the return format looks like. The current description leaves too many practical usage questions unanswered.
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% with the single parameter 'contractAddress' fully documented in the schema. The description doesn't add any additional parameter information beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete, but provides no extra value for 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 action ('Get') and resource ('floor price for an NFT collection'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_nft_metadata' or 'get_nft_sales' which also retrieve NFT collection data, leaving some ambiguity about when this specific tool is appropriate versus alternatives.
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 sibling tools. With multiple NFT-related tools available (get_nft_metadata, get_nft_sales, get_nfts_for_contract, etc.), there's no indication of when floor price retrieval is specifically needed versus other NFT data queries. The description simply states what it does without contextual usage information.
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 for behavioral disclosure. It states what the tool does but reveals nothing about behavioral traits: no information on rate limits, authentication requirements, error conditions, response format, or caching behavior (despite a 'refreshCache' parameter). The description is minimal and doesn't compensate for the lack of 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?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward tool. Every word earns its place, making it easy to parse quickly without unnecessary elaboration.
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 NFT metadata retrieval (involving blockchain contracts and tokens) and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what metadata is returned, potential errors, or how the tool behaves in different scenarios (e.g., invalid addresses). For a tool with four parameters and no structured output documentation, more context is needed.
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 all four parameters. The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter relationships, provide examples, or clarify semantics like token type implications. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't 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 action ('Get') and resource ('metadata for a specific NFT'), making the purpose immediately understandable. It distinguishes from siblings like 'get_nfts_for_owner' or 'get_nfts_for_contract' by focusing on individual NFT metadata rather than collections or lists. However, it doesn't explicitly contrast with 'get_token_metadata', which might be a similar sibling tool.
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. With many sibling tools for NFTs (e.g., get_nfts_for_owner, get_nft_sales, get_owners_for_nft), there's no indication of when this specific metadata retrieval is appropriate versus broader queries. No prerequisites, exclusions, or context for usage are mentioned.
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 'Get NFT sales data' which implies a read-only operation, but doesn't specify whether this requires API keys, has rate limits, returns paginated results, or what format the data comes in. The mention of 'contract or specific NFT' hints at filtering but lacks detail on how these interact. Significant behavioral gaps remain.
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?
Extremely concise single sentence that front-loads the core purpose. Every word earns its place with no redundant information. The structure is clear and efficiently communicates the tool's scope without unnecessary elaboration.
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 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, pagination behavior (implied by pageKey/pageSize but not described), error conditions, or how parameters interact. Given the complexity and lack of structured support, more contextual information is needed for effective 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 parameters are well-documented in the schema itself. The description adds minimal value beyond what's in the schema—it implies that 'contractAddress' and 'tokenId' are the primary filters, but doesn't explain their relationship (e.g., if tokenId requires contractAddress). Baseline 3 is appropriate since 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 action ('Get') and resource ('NFT sales data') with two distinct scopes ('for a contract or specific NFT'). It distinguishes from siblings like 'get_nft_metadata' or 'get_floor_price' by focusing on sales data, but doesn't explicitly differentiate from 'get_asset_transfers' which might overlap. The purpose is specific and unambiguous.
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 like 'get_asset_transfers' or 'get_transfers_for_contract'. The description implies usage for NFT sales queries but provides no context about prerequisites, limitations, or when other tools might be more appropriate. This leaves the agent to infer usage from parameter names 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 states the action but does not cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or pagination behavior. This is inadequate for a tool with multiple parameters and 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.
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 is front-loaded with the core purpose, making it easy to parse quickly, which is ideal for conciseness.
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 (5 parameters, no output schema, and no annotations), the description is insufficient. It does not explain return values, error conditions, or behavioral traits, leaving significant gaps for the agent to infer usage in a broader 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?
The input schema has 100% description coverage, providing clear details for all 5 parameters. The description adds no additional parameter semantics beyond implying the contractAddress is required, which is already covered in the schema. 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 verb 'Get' and the resource 'all NFTs for a contract', making the purpose immediately understandable. However, it does not differentiate from sibling tools like 'get_nfts_for_owner' or 'get_contracts_for_owner', which involve similar resources but different scopes, so it lacks 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 does not mention sibling tools like 'get_nfts_for_owner' for user-specific NFTs or 'get_nft_metadata' for individual NFT details, 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 states the tool retrieves NFTs but does not mention pagination behavior (implied by 'pageKey' and 'pageSize' in schema), rate limits, authentication needs, error conditions, or response format. For a read operation with multiple parameters, this is inadequate 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?
The description is a single, clear sentence with zero waste. It is front-loaded with the core purpose and appropriately sized for the tool's complexity. Every word earns its place, making it efficient and easy to parse.
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 (5 parameters, no output schema, no annotations), the description is incomplete. It lacks behavioral details (e.g., pagination, metadata inclusion effects), usage context relative to siblings, and output expectations. For a data retrieval tool with filtering and pagination, this leaves significant gaps 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 5 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or default behaviors). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.
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 NFTs owned by a specific wallet address'. It specifies the verb 'Get' and the resource 'NFTs', with the scope 'owned by a specific wallet address'. However, it does not explicitly differentiate from sibling tools like 'get_nfts_for_contract' or 'get_contracts_for_owner', which reduces clarity in a crowded toolset.
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. With multiple sibling tools for NFTs and owners (e.g., 'get_nfts_for_contract', 'get_contracts_for_owner', 'get_owners_for_nft'), there is no indication of context, prerequisites, or exclusions. This leaves the agent to infer usage from 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?
No annotations are provided, so the description carries full burden. It states 'Get owners' but doesn't disclose behavioral traits such as whether this is a read-only operation (implied but not explicit), pagination behavior (though schema hints at it), rate limits, authentication needs, or what the output looks like (e.g., list of addresses). This leaves significant gaps for a tool with 4 parameters.
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 zero waste—'Get owners of a specific NFT' is front-loaded and directly conveys the core purpose without unnecessary words. Every word earns its place, making it highly concise and well-structured.
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, no output schema, and 4 parameters (with 2 required), the description is incomplete. It lacks behavioral context (e.g., read-only nature, pagination details), output format, and usage guidelines, which are critical for an AI agent to invoke this tool correctly in a server with many NFT/blockchain-related siblings.
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 fully documents all parameters (contractAddress, tokenId, pageKey, pageSize). The description adds no meaning beyond this, as it doesn't explain parameter relationships (e.g., that contractAddress and tokenId uniquely identify an NFT) or usage nuances. Baseline 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 'Get owners of a specific NFT' clearly states the verb ('Get') and resource ('owners of a specific NFT'), making the purpose immediately understandable. It distinguishes from siblings like 'get_nfts_for_owner' (which gets NFTs for an owner) and 'get_nft_metadata' (which gets metadata), but could be more specific about what 'owners' entails (e.g., current holders vs. historical).
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 (e.g., needing contract address and token ID), exclusions, or comparisons to siblings like 'get_nfts_for_owner' or 'get_transfers_for_contract', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a read operation ('Get'), implying it's likely non-destructive, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what happens if token addresses are invalid. For a tool with no 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.
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 function without any fluff. It's front-loaded with the core action and target, making it easy to parse. Every word earns its place, achieving maximum clarity with minimal length.
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 (querying token balances, which may involve API calls and data formatting), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values (e.g., balance amounts, token symbols), error cases, or network specifics (e.g., Ethereum mainnet). For a tool with no structured output or behavioral hints, more context is needed.
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%, with clear descriptions for both parameters in the input schema. The description adds no additional parameter semantics beyond implying the address is for token balances, which is already covered by the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even without extra param info in the description.
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 ('token balances') with a specific target ('for a specific address'), making the purpose unambiguous. It distinguishes from siblings like 'get_nfts_for_owner' or 'get_tokens_for_owner' by focusing on token balances rather than NFTs or token ownership details. However, it doesn't explicitly differentiate from all possible alternatives, keeping it at a 4 rather than a 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 scenarios like checking balances for ERC-20 tokens, comparing with other tools like 'get_tokens_for_owner' (which might list tokens without balances), or prerequisites such as needing a valid wallet address. Without any usage context or exclusions, this is minimal guidance.
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 a read operation ('Get') but doesn't mention any behavioral traits such as rate limits, authentication needs, error handling, or what the metadata includes (e.g., token name, symbol, decimals). This leaves significant gaps for an AI agent.
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 action and resource, 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what metadata is returned (e.g., token details, contract info) or any behavioral aspects, which is inadequate for a tool that likely interacts with blockchain data and may have complexities.
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 'contractAddress' clearly documented. The description adds no additional meaning beyond the schema, such as format examples (e.g., Ethereum address format) or constraints. 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 verb 'Get' and the resource 'metadata for a token contract', making the purpose understandable. However, it doesn't distinguish this tool from similar sibling tools like 'get_nft_metadata' or 'get_contracts_for_owner', which also retrieve metadata-related information, so it lacks sibling 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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_nft_metadata' and 'get_contracts_for_owner' that might overlap in functionality, there's no indication of context, prerequisites, or exclusions for usage.
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 for behavioral disclosure. It only states the action ('Get tokens') without mentioning pagination behavior (implied by parameters), rate limits, authentication needs, error conditions, or what 'tokens' specifically refers to (e.g., ERC-20, ERC-721). This is inadequate for a tool with multiple parameters and 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.
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, though this conciseness comes at the cost of completeness.
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 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, pagination behavior, or how filtering works with 'contractAddresses'. For a data retrieval tool in a crowded sibling set, more context is needed to guide effective 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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'owner' is required and 'tokens' are retrieved, but doesn't clarify parameter interactions (e.g., how 'contractAddresses' filters results). Baseline 3 is appropriate since the schema handles most documentation.
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 'Get tokens owned by an address' clearly states the verb ('Get') and resource ('tokens owned by an address'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_nfts_for_owner' or 'get_token_balances', which reduces specificity.
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. With siblings like 'get_nfts_for_owner' and 'get_token_balances' available, there's no indication of differences in scope (e.g., tokens vs. NFTs vs. balances) or filtering capabilities, leaving usage context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it retrieves details but doesn't describe what 'details' include (e.g., sender, receiver, amount, status), whether it's a read-only operation, error handling for invalid hashes, or performance characteristics like rate limits. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence that front-loads the essential information. There is no wasted verbiage, making it easy to parse quickly while conveying the core functionality.
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 for effective tool use. It doesn't explain what transaction details are returned (e.g., fields, data structure), error conditions, or how it differs from sibling tools. For a data retrieval tool with no structured output documentation, this leaves too many unknowns.
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 description adds minimal value beyond the input schema, which has 100% coverage and fully documents the single 'hash' parameter. The description mentions 'by hash' but doesn't provide additional context like hash format, length, or examples. With high schema coverage, the baseline score of 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 with a specific verb ('Get') and resource ('transaction details'), specifying it retrieves details by hash. It distinguishes from some siblings like 'get_transaction_receipts' by focusing on transaction details rather than receipts, but doesn't explicitly differentiate from all similar tools like 'get_block_with_transactions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_transaction_receipts' for receipt information or 'get_block_with_transactions' for block context, nor does it specify prerequisites like needing a valid transaction hash.
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 a read operation ('Get') but does not cover aspects like rate limits, authentication needs, error handling, or the format of returned receipts. 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 with zero waste. It is front-loaded and appropriately sized for the tool's purpose, making it highly concise and well-structured.
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 lacks details on behavioral traits, return values, and usage context. For a tool with 2 parameters and no structured output, more information is needed to fully 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?
Schema description coverage is 100%, with clear descriptions for 'blockHash' and 'blockNumber'. The description adds no additional parameter semantics beyond what the schema provides, such as format details or usage examples. 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 verb ('Get') and resource ('transaction receipts for a block'), making the purpose specific and understandable. However, it does not explicitly differentiate from siblings like 'get_transaction' or 'get_block_with_transactions', which might also retrieve transaction-related data, 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 does not mention prerequisites, exclusions, or compare to siblings such as 'get_transaction' or 'get_block_with_transactions', leaving usage context implied at best.
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 states the tool retrieves transfers but lacks details on what data is returned (e.g., transfer details, pagination behavior, error handling), whether it's read-only (implied but not explicit), rate limits, or authentication needs. This leaves significant gaps for an agent to understand 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 a single, efficient sentence that directly states the tool's purpose without 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 complexity (6 parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances like pagination (implied by 'pageKey' but not described). For a data retrieval tool with multiple filtering options, more context is needed to guide effective 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%, meaning all parameters are documented in the schema itself. The description adds no additional semantic context beyond implying the tool involves transfers and an NFT contract, which is already covered by parameter descriptions. This meets the baseline score of 3 for high schema coverage without extra value from the description.
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 transfers') and target resource ('for an NFT contract'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_asset_transfers' or 'get_transfers_for_owner', which handle similar transfer data but with different scopes or parameters.
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 like 'get_asset_transfers' (for broader asset types) or 'get_transfers_for_owner' (for owner-specific transfers), nor does it specify prerequisites such as needing a valid contract address or appropriate blockchain access.
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 but offers minimal information. It doesn't mention whether this is a read-only operation (implied by 'Get'), potential rate limits, authentication needs, pagination behavior beyond the 'pageKey' parameter, or what the output format looks like (e.g., list of transfers with details). The description is too brief to cover these aspects adequately.
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 zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward query tool and front-loaded with the core action. 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 complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values (e.g., transfer details like timestamps, token IDs), behavioral traits like pagination or rate limits, or how it integrates with sibling tools. For a tool with multiple filtering options and no structured output definition, more context is needed to guide effective 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 schema already documents all 7 parameters thoroughly with descriptions and enums. The description adds no additional meaning beyond what's in the schema—it doesn't clarify parameter interactions, default values, or usage examples. This meets the baseline of 3 since 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 verb ('Get') and resource ('NFT transfers for an owner'), making the purpose immediately understandable. It distinguishes from siblings like 'get_asset_transfers' (broader asset types) and 'get_transfers_for_contract' (different scope), though not explicitly. However, it lacks specificity about what 'transfers' entails (incoming, outgoing, or both).
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. For example, it doesn't explain how it differs from 'get_asset_transfers' (which might include fungible tokens) or 'get_nfts_for_owner' (which might show current holdings rather than transfer history). The description offers no context about prerequisites, timing, or exclusions.
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 but only states the action without behavioral details. It doesn't disclose whether this is a long-running operation, how events are delivered (e.g., via WebSocket, callback), error handling, or any rate limits. This leaves significant gaps for an agent to understand how to use it effectively.
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 zero waste. It's front-loaded and directly conveys the core action without unnecessary elaboration, 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 a subscription tool (likely involving real-time events and state management), no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after subscription, how to handle responses, or integration with 'unsubscribe,' leaving critical context gaps for proper usage.
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 well. The description adds no additional meaning about parameters beyond implying subscription to 'blockchain events,' which aligns with the schema's enum values. 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 verb ('subscribe') and resource ('blockchain events'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'unsubscribe' or explain what subscription entails beyond the basic action.
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 about when to use this tool versus alternatives like polling with other sibling tools (e.g., get_block_number, get_transaction). The description lacks context about subscription scenarios, prerequisites, or comparisons to other methods for monitoring blockchain events.
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 states the action but doesn't cover critical aspects like whether this is a destructive operation, permission requirements, error conditions, or what happens after unsubscribing. This is inadequate for a mutation 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 extremely concise with just four words, front-loading the core action without any wasted words. It efficiently communicates the tool's purpose in minimal space.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits, error handling, and what to expect after invocation, which is insufficient for an agent to use it effectively in 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%, with the single parameter 'subscriptionId' well-documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
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 ('Unsubscribe from') and resource ('blockchain events'), providing a specific action. However, it doesn't explicitly differentiate from its sibling 'subscribe' beyond the opposite action, missing an opportunity to clarify the relationship between these two 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing subscription), nor does it reference the sibling 'subscribe' tool for context, leaving the agent without usage context.
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 action ('lookup') but does not describe traits like read-only status, potential errors (e.g., invalid address, no ENS name), rate limits, or output format. For a tool with no annotations, this leaves significant gaps in understanding its 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 a single, efficient sentence: 'Lookup the ENS name for an address'. It is front-loaded with the core action and resource, with zero wasted words. This makes 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral details (e.g., what happens if no ENS exists) and usage guidelines. For a lookup tool in a blockchain context, more context on failures or output 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?
The input schema has 100% description coverage, with the 'address' parameter documented as 'The address to lookup'. The description adds no additional meaning beyond this, such as format details (e.g., Ethereum address) or examples. With high schema coverage, the baseline is 3, as the schema handles 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: 'Lookup the ENS name for an address' specifies the verb ('lookup'), resource ('ENS name'), and target ('address'). It distinguishes from most siblings (e.g., 'get_block_number', 'get_transaction') but not explicitly from 'resolve_ens', which might be a reverse operation. The purpose is specific but lacks sibling differentiation for the closest related tool.
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 does not mention prerequisites (e.g., address format), exclusions, or compare to siblings like 'resolve_ens' (which might resolve ENS to address). Without such context, an agent might misuse it or overlook better options.
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 but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what happens with invalid names, rate limits, authentication requirements, or error conditions. The description states what the tool does but not how it 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 states the core functionality without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the 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?
For a simple resolution tool with good schema coverage but no annotations or output schema, the description is minimally adequate. It explains what the tool does but lacks behavioral context and doesn't address the reverse lookup alternative. The description meets basic requirements but leaves gaps in usage 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?
The schema has 100% description coverage, so parameters are well-documented in the structured data. The description adds no additional parameter semantics beyond what's already in the schema, which is acceptable but not value-adding. Baseline 3 is appropriate when 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 with a specific verb ('resolve') and resource ('ENS name'), making it immediately understandable. However, it doesn't differentiate from sibling 'lookup_address' which performs a reverse operation, missing an opportunity for full 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention the sibling 'lookup_address' tool for reverse resolution or clarify typical use cases for ENS resolution, leaving the agent without contextual usage direction.
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 action but doesn't clarify if this is a read-only operation, how frequently it can be called, what network or blockchain it targets, or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, clear sentence with no wasted words. It's front-loaded with the essential information ('Get the latest block number'), making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks context about the blockchain environment, return format, or error handling, which could be helpful for an AI agent to use it correctly in varied scenarios.
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 zero parameters, and the schema description coverage is 100%, so there's no need for parameter documentation in the description. The description correctly focuses on the tool's purpose without unnecessary parameter details, earning a baseline high score for this dimension.
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 with a specific verb ('Get') and resource ('latest block number'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_block_with_transactions', which might retrieve more detailed block information.
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. With siblings like 'get_block_with_transactions' that might return similar or overlapping data, there's no indication of trade-offs, prerequisites, or specific contexts where this simpler tool is preferred.
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:

[![alchemy-sdk-mcp MCP server](https://glama.ai/mcp/servers/itsanishjain/alchemy-sdk-mcp/badges/card.svg)](https://glama.ai/mcp/servers/itsanishjain/alchemy-sdk-mcp)

Score Badge

Copy to your README.md:

[![alchemy-sdk-mcp MCP server](https://glama.ai/mcp/servers/itsanishjain/alchemy-sdk-mcp/badges/score.svg)](https://glama.ai/mcp/servers/itsanishjain/alchemy-sdk-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/itsanishjain/alchemy-sdk-mcp'

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