Model Context Protocol Server for Solana Client

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific Solana blockchain operations, such as account queries, block retrieval, transaction handling, and token operations. The descriptions precisely define unique functions with no overlapping responsibilities, making tool selection unambiguous for an agent.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern (e.g., get_account_info, confirm_transaction, request_airdrop). The naming is uniformly snake_case throughout, with clear and predictable structures that enhance readability and predictability.
Tool Count2/5
With 44 tools, the count is excessive for a single server, likely overwhelming for agents and causing decision fatigue. While Solana is a complex domain, this many tools suggests poor scoping, as many could be consolidated or omitted without losing functionality.
Completeness5/5
The toolset provides comprehensive coverage of Solana client operations, including account management, transaction processing, block queries, token functions, network info, and administrative actions. There are no obvious gaps; it supports full CRUD and lifecycle workflows for the domain.
Average 3.2/5 across 44 of 44 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
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 are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns fee information but doesn't describe what that entails (e.g., is it a read-only operation, does it simulate a transaction, are there rate limits, or what format the fee information takes). This leaves significant gaps in understanding the tool's behavior beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the purpose in the first sentence. The 'Args' and 'Returns' sections are structured clearly, though they could be more integrated. There's minimal waste, but the formatting as a docstring might be slightly verbose for an MCP context.
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 (a fee calculation tool with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like read-only nature, error conditions, or what the fee information includes (e.g., numeric value, breakdown). For a tool that likely interacts with a blockchain or payment system, more context is needed for effective use.
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 description coverage is 0%, so the schema provides no parameter details. The description includes an 'Args' section that lists parameters (from_pubkey, to_pubkey, lamports) and their types, adding some meaning beyond the bare schema. However, it doesn't explain what these parameters represent (e.g., lamports as a currency unit, pubkeys as identifiers) or constraints, which is insufficient given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns the fee for a message.' It specifies the verb ('Returns') and resource ('fee for a message'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'send_transaction' or 'request_airdrop', which might also involve fees or 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 prerequisites (e.g., needing to check fees before sending a transaction), exclusions, or comparisons to sibling tools like 'send_transaction' (which might involve fees) or other fee-related operations. Usage is implied but not explicitly stated.
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 this is a read operation ('Returns'), but doesn't cover critical aspects like whether it requires authentication, rate limits, pagination behavior, error conditions, or what format the returned information is in. For a tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose in the first sentence. The Args and Returns sections are structured clearly, though the return description ('Token accounts information') is vague. There's no wasted text, making it efficient overall.
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 blockchain tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return format, error handling, authentication needs, and how it differs from sibling tools. For a tool in this context, more comprehensive information 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds minimal value by listing the parameters ('delegate' and 'mint') with brief explanations, but these are basic and don't clarify format (e.g., public key encoding), constraints, or examples. It doesn't compensate adequately for the lack of schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('all SPL Token accounts by approved delegate'). It distinguishes itself from siblings like 'get_token_accounts_by_owner' by specifying the delegate-based filtering. However, it doesn't explicitly mention what makes it unique beyond the name, slightly reducing clarity.
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 prefer it over similar tools like 'get_token_accounts_by_owner' or 'get_token_account_balance', nor does it specify prerequisites or exclusions. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the action ('Request to have the validator exit') but doesn't disclose critical behavioral traits: whether this is a destructive operation, requires specific permissions, has irreversible consequences, or involves network changes. The return value description ('Validator exit request result') is vague.
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 brief and front-loaded with the core purpose in the first sentence. The second sentence about returns is somewhat redundant but not wasteful. Overall, it's efficiently structured with minimal fluff.
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 (likely a significant network operation), lack of annotations, no output schema, and vague return description, the description is incomplete. It doesn't explain what 'validator exit' entails, success/failure conditions, or system impacts, leaving critical context gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which aligns with the schema. Baseline is 4 for zero-parameter tools when schema coverage is complete.
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 states the tool's purpose as 'Request to have the validator exit', which is a clear verb+action. However, it doesn't specify what a 'validator' is in this context or differentiate from sibling tools like 'get_account_info' or 'send_transaction'. The purpose is understandable but lacks domain-specific clarity.
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. Given sibling tools include various read operations and actions like 'request_airdrop' or 'send_transaction', there's no indication of prerequisites, timing, or contextual triggers for validator exit requests.
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 'estimated production time' and the return format, but doesn't cover critical aspects like whether this is a read-only operation, potential errors, rate limits, or network dependencies. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 and appropriately sized, with a clear purpose statement followed by parameter and return details in separate sections. Every sentence adds value, and there is no unnecessary information, 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.
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 (one parameter, no output schema, no annotations), the description is reasonably complete for basic usage. It explains what the tool does, the parameter, and the return format. However, it lacks context on behavioral traits and usage guidelines, which could be important for an agent in a server with many similar tools.
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 includes an 'Args' section that documents the 'slot' parameter as a 'Block slot number', adding meaning beyond the schema's minimal coverage (0%). However, with only one parameter and the schema providing no descriptions, the description compensates adequately but doesn't fully detail constraints or examples, keeping it at a baseline level.
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 ('Fetch') and resource ('estimated production time of a block'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_block' or 'get_block_height', which might also retrieve block-related information, 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. With many sibling tools related to blocks (e.g., get_block, get_block_height, get_blocks), there is no indication of specific use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it states the tool returns leader schedule information, it doesn't explain what format this information comes in, whether it's paginated, if there are rate limits, or any authentication requirements. The description is minimal and lacks important operational context.
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 efficiently structured with clear sections for Args and Returns, making it easy to parse. It's appropriately sized for a single-parameter tool, though the 'Returns' section could be more informative about the format of the returned information.
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 that there are no annotations and no output schema, the description is insufficiently complete. It doesn't explain what leader schedule information looks like, how it's structured, or provide any examples. For a tool that presumably returns structured data about blockchain leadership, more context 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?
The description includes an Args section that documents the single parameter 'epoch' as optional, which adds value beyond the input schema's 0% description coverage. However, it doesn't explain what an epoch is in this context, what values are valid, or what happens when the parameter is omitted (default behavior).
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 ('Returns') and resource ('leader schedule for an epoch'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_epoch_info' or 'get_epoch_schedule', which might be related but serve different functions.
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_epoch_info' and 'get_epoch_schedule' available, there's no indication of how this tool differs or when it's appropriate to use it over those 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'returns' information, implying a read-only operation, but doesn't clarify authentication needs, rate limits, error conditions, or what 'account information' entails (e.g., data format, completeness). For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by Args and Returns sections. It uses minimal sentences efficiently, though the 'Returns: str: Multiple accounts information' is vague and could be more specific. There's no wasted text, making it appropriately concise for its complexity.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., read-only nature, potential errors), parameter constraints, and the structure of returned data. For a tool with 2 parameters and significant context gaps, it should provide more guidance to ensure correct agent 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 0%, so the schema provides no parameter descriptions. The description adds basic semantics: 'pubkeys (list[str]): List of account public keys' and 'encoding (str): Encoding for the account data.' This clarifies the purpose of both parameters, but doesn't detail encoding options (e.g., base64 vs. json) or pubkey format constraints. It partially compensates for the schema gap, earning a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns the account information for a list of public keys.' It specifies the verb ('returns') and resource ('account information'), and distinguishes it from sibling tools like get_account_info (singular) and get_balance (balance-specific). However, it doesn't explicitly differentiate from other account-related tools like get_program_accounts or get_token_accounts_by_owner.
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 prefer get_multiple_accounts over get_account_info (for single accounts) or other account retrieval tools, nor does it specify prerequisites or exclusions. 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns statuses but doesn't describe what 'statuses' entail (e.g., confirmed, failed, pending), potential errors, rate limits, or authentication needs. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 and appropriately sized, with a clear purpose statement followed by parameter and return value sections. It avoids unnecessary fluff, though the return format description could be more concise. Overall, it's efficient and front-loaded with key information.
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, no output schema, and minimal schema description coverage (0%), the description is incomplete. It doesn't explain what 'statuses' mean, how they're formatted beyond a basic string, or potential behavioral aspects like error handling. For a tool in a complex domain (blockchain/transactions), more context 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?
The description includes an 'Args' section that explains the 'signatures' parameter as 'List of transaction signatures to confirm', adding meaning beyond the schema's minimal coverage (0%). However, it doesn't detail format constraints (e.g., signature length, encoding) or provide examples, leaving some ambiguity. With one parameter and partial compensation, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns the statuses of a list of signatures.' It specifies the verb ('returns') and resource ('statuses of signatures'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_transaction' or 'confirm_transaction', which might also provide status-related 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. It doesn't mention sibling tools like 'confirm_transaction' or 'get_transaction', which could be related, nor does it specify prerequisites or contexts for usage. This leaves the agent without clear direction on 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. It states the tool returns data ('Returns all SPL Token accounts'), implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, error conditions, or what 'all' means (e.g., pagination, limits). For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by structured Args and Returns sections. There's minimal waste, though the Returns section could be more informative (e.g., specifying JSON format instead of just 'str').
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 (2 required parameters, no annotations, no output schema), the description is incomplete. It lacks details on return format (beyond 'str'), error handling, performance considerations, and how it differs from sibling tools. For a blockchain-related tool with specific parameter formats, this leaves too much ambiguity.
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 0%, so the schema provides no parameter descriptions. The description adds basic semantics: 'owner (str): Public key of token owner' and 'mint (str): Token mint address', clarifying what each parameter represents. However, it doesn't provide format details (e.g., base58 encoding), validation rules, or examples, leaving gaps for a tool with 2 required parameters.
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: 'Returns all SPL Token accounts by token owner.' It specifies the verb ('Returns'), resource ('SPL Token accounts'), and scope ('by token owner'). However, it doesn't explicitly differentiate from sibling tools like 'get_token_accounts_by_delegate' or 'get_token_account_balance', which would require 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 sibling tools like 'get_token_accounts_by_delegate' (which uses a delegate instead of owner) or 'get_token_account_balance' (which returns balance info rather than accounts). There's no context about prerequisites 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns token supply information, but lacks details on permissions, rate limits, error conditions, or whether it's a read-only operation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the main purpose stated first followed by parameter and return details. It avoids unnecessary verbosity, though the structure could be slightly improved by integrating the parameter explanation more seamlessly.
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 (one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose and parameter semantics but lacks behavioral context and usage guidelines, which are important for effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining that the 'mint' parameter is the 'Public key of token mint', which clarifies its purpose beyond the schema's generic 'Mint' title. However, with 0% schema description coverage and only one parameter, the description compensates adequately but does not provide extensive details like format examples or constraints.
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 ('Returns') and resource ('total supply of an SPL Token type'), making it easy to understand what the tool does. However, it does not explicitly differentiate from sibling tools like 'get_supply' or 'get_token_account_balance', which might handle related but different queries.
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_supply' and 'get_token_account_balance' present, there is no indication of the specific context or scenarios where this tool is preferred, leaving the agent to infer 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 the full burden of behavioral disclosure. It states the action ('Request an airdrop') but doesn't clarify if this is a read-only or mutating operation, what permissions are needed, whether it's reversible, or any rate limits. The return value is vaguely described as 'Airdrop request result' without detailing success/failure outcomes.
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 a clear opening sentence followed by Args and Returns sections. It's appropriately sized for a simple tool, with no redundant information. However, the 'Returns' section could be more informative, slightly reducing efficiency.
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, 0% schema coverage, and no output schema, the description is incomplete for a mutating tool. It lacks details on behavioral traits (e.g., idempotency, side effects), error handling, and practical usage context. The return value description is too vague to be helpful without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds basic semantics by explaining 'address' as 'Public key of recipient' and 'lamports' as 'Amount of lamports to request', which clarifies the purpose of each parameter. However, it doesn't provide format details (e.g., address encoding, lamports range) or constraints beyond what's implied.
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 ('Request an airdrop') and the resource ('lamports to a Pubkey'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_balance' or 'send_transaction' by focusing on airdrop requests specifically. However, it doesn't explicitly differentiate from potential similar tools (none exist in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., network conditions, availability), limitations (e.g., rate limits, testnet-only), or when not to use it. Siblings include 'send_transaction' for general transfers, but no comparison is made.
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 mentions the transaction must be 'signed and serialized,' hinting at prerequisites, but fails to disclose critical behaviors: whether this is a write operation (implied by 'send'), potential side effects (e.g., fund transfers), error conditions, network dependencies, or response details. For a mutation tool with zero annotation coverage, this is inadequate.
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 and front-loaded with the core purpose, followed by Args and Returns sections. It avoids redundancy and uses minimal sentences. However, the 'Returns' section could be more informative (e.g., explaining what 'Transaction send result' entails), slightly reducing efficiency.
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 (a write operation with financial implications), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It misses behavioral details, error handling, and return value specifics, making it insufficient for safe and effective use by 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 0%, so the description must compensate. It adds meaning by explaining 'txn' as 'Signed transaction as bytes,' clarifying the parameter's purpose and format beyond the schema's 'binary' type. However, it doesn't detail encoding, size limits, or validation rules, leaving gaps. With one parameter, baseline is 4, but incomplete compensation lowers it to 3.
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 ('send a transaction') and specifies the resource ('transaction that has already been signed and serialized into the wire format'). It distinguishes from siblings like 'confirm_transaction' or 'get_transaction' by focusing on submission rather than querying or confirmation. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it implies usage for sending pre-signed transactions, but offers no explicit when-to-use rules, alternatives (e.g., vs. 'request_airdrop' for token transfers), or exclusions. With many sibling tools, this lack of context leaves the agent guessing about appropriate scenarios.
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 returns a list of confirmed blocks, which implies a read-only operation, but doesn't specify details like rate limits, authentication needs, error handling, or what 'confirmed' means in this context. The description adds minimal behavioral context beyond the basic 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 well-structured with clear sections (purpose, Args, Returns), making it easy to parse. It's appropriately sized—two sentences for the core purpose plus parameter details—with no wasted words. However, the 'Returns' section could be more concise by integrating with the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description provides basic purpose and parameter documentation but lacks depth. It doesn't cover behavioral aspects like error cases or performance, and the return format description ('List of blocks in the format "Blocks: {blocks}"') is vague. For a tool with two parameters and no structured support, this is minimally adequate but has clear gaps.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It includes an 'Args' section that documents both parameters (start_slot and end_slot) with types and defaults, adding meaningful semantics beyond the schema. However, it doesn't explain what 'slots' are in this context (e.g., blockchain slots) or provide usage examples, leaving gaps in 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: 'Returns a list of confirmed blocks between two slots.' It specifies the verb ('returns'), resource ('confirmed blocks'), and scope ('between two slots'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_block' (singular) or 'get_block_height', which might retrieve different block-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it returns blocks 'between two slots,' suggesting it's for retrieving a range of blocks. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_block' (for a single block) or 'get_block_height' (for height information). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format ('Performance samples: {samples}') and ordering ('reverse slot order'), which adds some behavioral context. However, it lacks critical details: whether this is a read-only operation, potential rate limits, authentication needs, or what 'performance samples' represent (e.g., metrics, timestamps). 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 well-structured and concise. It starts with the core purpose, then details the parameter and return format in separate sections. Every sentence adds value: the first defines the tool, the second explains the parameter, and the third specifies the return format. No wasted words.
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 (performance data retrieval), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'performance samples' are, their structure, or how they relate to blockchain concepts (e.g., slots). Without this context, an agent may struggle to use the tool effectively or interpret results.
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 description adds meaningful semantics beyond the schema. The schema has 0% description coverage and only shows 'limit' as an optional integer. The description clarifies that 'limit' is 'Number of samples to return (maximum 720)', specifying the purpose and constraint. With 1 parameter and low schema coverage, this adequately compensates.
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: 'Returns a list of recent performance samples, in reverse slot order.' It specifies the verb ('returns'), resource ('performance samples'), and ordering ('reverse slot order'), which distinguishes it from generic 'get' tools. However, it doesn't explicitly differentiate from sibling tools like 'get_block' or 'get_slot', which also retrieve blockchain data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention what 'performance samples' are, their use cases, or how this tool differs from other data retrieval tools in the sibling list (e.g., 'get_block', 'get_transaction'). This leaves 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 full burden. It states 'Fetch' which implies a read operation, but doesn't disclose behavioral traits like whether this requires authentication, rate limits, error conditions, or what format the commitment information takes. The description is minimal and lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with clear sections (purpose, args, returns). The first sentence states the core purpose, followed by structured parameter and return documentation. There's no wasted text, though it could be slightly more front-loaded with the most critical 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 single-parameter read operation with no output schema, the description is minimally adequate. It covers the basic purpose and parameter meaning, but lacks important context about what 'commitment information' actually contains, error handling, or performance characteristics. Without annotations, it should provide more operational guidance.
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?
With only 1 parameter and 0% schema description coverage, the description compensates well by explaining that 'slot' is a 'Block slot number to query'. This adds meaningful semantic context beyond what the bare schema provides. The description effectively clarifies the parameter's purpose and usage.
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 ('Fetch') and resource ('commitment for particular block'), making the purpose evident. It distinguishes itself from siblings like 'get_block' or 'get_block_time' by focusing specifically on commitment information. However, it doesn't explicitly differentiate from all possible siblings in the list, keeping it at 4 rather than 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. With siblings like 'get_block', 'get_blocks', and 'get_block_time', there's no indication of when commitment information is needed versus other block data. The description lacks any context about use cases 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 carries full burden for behavioral disclosure. While it indicates this is a read operation ('returns information'), it doesn't address important behavioral aspects like whether this requires authentication, rate limits, network latency considerations, or what happens if the cluster is unavailable. The return format description is helpful but insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve a clear purpose: the first states what the tool does, the second describes the return format. There's no wasted text. It could be slightly more front-loaded if the return format was integrated into the first sentence, but it's still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with no output schema, the description provides basic but incomplete context. It explains what information is returned and the format, but doesn't address behavioral aspects (auth, errors, performance) or differentiate from similar tools. Given the lack of annotations and output schema, more completeness would be expected for a cluster information tool in a complex blockchain context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description appropriately doesn't discuss parameters since none exist. It does add value by specifying the return format ('Cluster nodes: {nodes}'), which provides semantic context beyond what the schema could convey for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns information about all the nodes participating in the cluster.' This specifies the verb ('returns information') and resource ('nodes participating in the cluster'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_vote_accounts' or 'get_leader_schedule' which might also provide cluster-related information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that retrieve various types of cluster/network information (e.g., get_vote_accounts, get_leader_schedule, get_slot_leader), there's no indication of what specific 'node information' this provides or when it's the appropriate choice. The description only states what it does, not when to use it.
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 returns information but doesn't specify if it's a read-only operation, potential side effects, error conditions, or performance traits like rate limits. The return type hint ('str: First available block information') adds minimal context, but overall, it's insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the first sentence stating the core purpose clearly. The second sentence adds a return type hint, which is useful but could be integrated more seamlessly. There's no wasted text, making it efficient, though minor structural improvements 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?
Given the tool has 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavioral aspects (e.g., read-only nature, error handling) and doesn't differentiate from siblings. For a simple query tool, this is passable but leaves gaps in usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately omits parameter information, avoiding redundancy. No additional semantics are required or provided.
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: 'Returns the slot of the lowest confirmed block available.' This specifies the verb ('returns'), resource ('slot'), and scope ('lowest confirmed block available'), making it distinct from siblings like get_block, get_blocks, or get_latest_blockhash. However, it doesn't explicitly differentiate from get_minimum_ledger_slot, which might be similar, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to blocks and slots (e.g., get_block, get_blocks, get_minimum_ledger_slot), the description lacks context on use cases, prerequisites, or exclusions, leaving the agent to infer usage based on 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 the return format ('Genesis hash: {hash}'), which adds some context, but lacks details on permissions, rate limits, or error handling. For a tool with zero annotation coverage, this is insufficient to fully inform the agent about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the purpose stated clearly in the first sentence. The second sentence adds necessary return format details without redundancy. It could be slightly more structured by integrating the return format into the main sentence, but overall, it's efficient and wastes no words.
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 has gaps. It explains what the tool does and the return format, but lacks usage guidelines and behavioral context like error handling. For a basic read operation, this is minimal viable but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add any parameter details, which is appropriate here. A baseline of 4 is applied since there are no parameters to document, and the schema fully covers this aspect.
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: 'Returns the genesis hash.' It specifies the verb ('Returns') and resource ('genesis hash'), making it unambiguous. However, it doesn't explicitly differentiate from siblings like 'get_block' or 'get_latest_blockhash', which might also return hash-related data, 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 context, prerequisites, or compare it to sibling tools such as 'get_latest_blockhash' or 'get_block', leaving the agent to infer usage based on 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 full burden. It only states what the tool returns, without mentioning behavioral aspects like whether it's a read-only operation, potential rate limits, authentication requirements, or how current 'current' actually is (real-time vs cached). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one stating the purpose and one describing the return format. It's front-loaded with the core functionality first. The return format description could potentially be more concise, but overall it's efficient.
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 zero-parameter read operation with no output schema, the description covers the basic purpose and return format. However, it lacks important context about what an 'inflation governor' actually represents in this system, and with no annotations, it should provide more behavioral transparency about the operation's characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description correctly indicates no parameters are needed by not mentioning any, which aligns perfectly with the empty input 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's purpose: 'Returns the current inflation governor.' This is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_inflation_rate' or 'get_inflation_reward', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_inflation_rate' and 'get_inflation_reward' available, there's no indication of when this specific inflation-related query is appropriate versus those other 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns inflation values but does not explain what 'current epoch' means, whether this is a read-only operation, potential rate limits, or error conditions. For a tool with zero annotation coverage, this is insufficient, though it minimally describes the return format.
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 the main purpose stated first and return format details following. Both sentences earn their place by providing essential information without redundancy, though the return format could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is moderately complete. It explains what the tool does and the return format, but lacks context on behavior, usage, or differentiation from siblings, leaving gaps for an AI agent to understand full applicability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description does not need to add parameter semantics, so a baseline score of 4 is appropriate, as it efficiently avoids unnecessary details while matching 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's purpose: 'Returns the specific inflation values for the current epoch.' It specifies the verb ('returns'), resource ('inflation values'), and scope ('current epoch'). However, it does not explicitly differentiate from sibling tools like 'get_inflation_governor' or 'get_inflation_reward', which reduces the score from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any mention of prerequisites, context, or comparisons to sibling tools such as 'get_inflation_governor' or 'get_inflation_reward', leaving the agent without explicit usage instructions.
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 returns reward information but doesn't describe the format, whether it's read-only, if it has rate limits, or any side effects. For a tool with no annotation coverage, this is inadequate, as it leaves key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated first, followed by structured Arg and Return sections. Every sentence adds value, and there's no wasted text. However, the structure could be slightly improved by integrating usage context into the flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameters well but lacks behavioral details, usage guidelines, and output format explanation. Without annotations or output schema, it should do more to compensate, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'pubkeys (list[str]): List of account addresses' and 'epoch (Optional[int]): Epoch for which to calculate rewards,' clarifying what each parameter represents beyond the schema's basic types. This covers both parameters effectively, though it could provide more detail on epoch defaults or pubkey formats.
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: 'Returns the inflation/staking reward for a list of addresses for an epoch.' It specifies the verb ('returns'), resource ('inflation/staking reward'), and scope ('list of addresses for an epoch'), distinguishing it from siblings like get_inflation_rate or get_inflation_governor. However, it doesn't explicitly differentiate from all siblings, such as get_balance or get_account_info, which might also provide reward-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for historical or current data, or how it differs from similar tools like get_inflation_rate. With many sibling tools available, this lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format ('str: Largest accounts info in the format "Largest accounts: {accounts}"'), which adds some behavioral context. However, it lacks details on permissions, rate limits, network effects, or error conditions, which are important for a read operation in a blockchain context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second clarifies the return format. There's no wasted text, though the formatting of the return statement could be slightly cleaner (e.g., avoiding nested quotes).
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 minimally adequate. It explains what the tool does and the return format, but for a blockchain tool with many siblings, more context on usage or limitations would improve completeness. The lack of annotations means the description should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate. It correctly avoids unnecessary parameter details, focusing on the tool's output instead.
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: 'Returns the 20 largest accounts, by lamport balance.' It specifies the verb ('Returns'), resource ('largest accounts'), and scope ('20 largest, by lamport balance'). However, it doesn't explicitly differentiate from sibling tools like 'get_token_largest_accounts' or 'get_account_info', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'get_account_info', 'get_token_largest_accounts'), there's no indication of context, prerequisites, or exclusions. The agent must infer usage from the purpose 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. It states the tool returns a string in a specific format, which is useful, but does not disclose behavioral traits like whether this is a read-only operation, if it has rate limits, or what happens with invalid inputs. The description adds minimal context beyond the basic return format, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the main purpose stated first, followed by structured sections for Args and Returns. Each sentence earns its place by providing essential information, though the return format could be more succinctly integrated. There is minimal waste, but slight room for improvement in flow.
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. It covers the purpose, parameter semantics, and return format, but lacks usage guidelines and behavioral transparency. For a simple query tool, this is acceptable but has clear gaps, especially in guiding the agent on when and how to use it effectively.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'size' represents 'Account data length', which clarifies the parameter's purpose beyond the schema's title 'Size'. However, it does not provide details on units, constraints, or examples, leaving some ambiguity. With one parameter and partial semantic enhancement, this scores above baseline.
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: 'Returns minimum balance required to make account rent exempt.' It specifies the verb ('returns'), resource ('minimum balance'), and context ('rent exempt'), but does not explicitly differentiate it from sibling tools like 'get_balance' or 'get_account_info', which might also return balance-related information. The purpose is clear but 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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, such as needing account data length, or suggest other tools for related tasks like checking actual balances. Usage is implied only through the parameter 'size', but no explicit context or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a string with minimum ledger slot information, but does not disclose behavioral traits like potential errors, performance characteristics, or whether the data is cached or real-time. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the first sentence clearly stating the purpose. The second sentence specifies the return type, which is useful. However, the formatting with 'Returns:' could be slightly more integrated, but overall it is efficient with minimal waste.
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 has no parameters and no output schema, the description provides basic purpose and return type. However, it lacks details on behavioral aspects and usage context, which are important for a tool in a complex environment like blockchain ledger queries. This makes it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%. With no parameters to document, the description does not need to add parameter semantics. A baseline of 4 is appropriate as it avoids redundancy and focuses on the tool's purpose.
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: 'Returns the lowest slot that the node has information about in its ledger.' It specifies the verb ('returns') and resource ('lowest slot'), but does not explicitly differentiate from siblings like 'get_slot' or 'get_first_available_block', which reduces it from 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 lacks context about scenarios where knowing the minimum ledger slot is useful compared to other slot-related tools in the sibling list, such as 'get_slot' or 'get_first_available_block'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the return format as a string, which adds some behavioral context, but fails to disclose critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or pagination behavior for large result sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args/Returns sections are structured but slightly verbose; the return format explanation could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is minimally adequate. It covers the basic purpose and parameter meaning but lacks details on behavioral traits, error handling, or output structure beyond a string format, leaving gaps for effective tool use.
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?
With 0% schema description coverage and only 1 parameter, the description compensates well by explaining that 'program_id' is a 'Pubkey of program to query'. This adds meaningful semantics beyond the schema's generic 'Program Id' title, though it could specify the expected format (e.g., base58 string).
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 ('Returns') and resource ('all accounts owned by the provided program Pubkey'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_account_info' or 'get_multiple_accounts' that also retrieve account information, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_account_info' (for single accounts) or 'get_multiple_accounts' (for specific accounts), 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 returns 'confirmed signatures' and mentions parameters for filtering, but doesn't describe important behaviors like rate limits, authentication requirements, error conditions, pagination, or what 'Signatures information' entails. For a query tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by organized parameter and return sections. Every sentence adds value, with no redundant or vague phrasing. It could be slightly more concise by integrating the 'Args' and 'Returns' labels more seamlessly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters adequately but lacks behavioral details (e.g., performance, errors) and doesn't explain the return value beyond 'Signatures information'. For a query tool with siblings, more context on differentiation and output format would improve completeness.
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 description includes an 'Args' section that documents all four parameters with brief explanations, adding meaningful context beyond the input schema (which has 0% description coverage). It clarifies that 'account' is the address to query, 'before' and 'until' are for searching signatures, and 'limit' controls the maximum return count. This compensates well for the schema's lack of descriptions.
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: 'Returns confirmed signatures for transactions involving an address.' It specifies the verb ('returns'), resource ('confirmed signatures'), and scope ('transactions involving an address'). However, it doesn't explicitly differentiate from sibling tools like 'get_signature_statuses' or 'get_transaction', which could have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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_signature_statuses' or 'get_transaction', nor does it specify prerequisites, constraints, or typical use cases. The agent must infer usage from the purpose 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 the tool returns version information, implying a read-only operation, but doesn't disclose any behavioral traits such as rate limits, error conditions, or whether it requires specific permissions. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence clearly stating the purpose. The second sentence adds return format details, which is useful. There's no wasted text, and it's structured efficiently, though it could be slightly more polished (e.g., integrating the return format into the main sentence).
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 (0 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what the tool returns but lacks behavioral context (e.g., performance or error handling). Without annotations or an output schema, the description should ideally provide more details on the return value's structure or usage constraints, but it's minimally adequate for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add any parameter semantics, which is appropriate here. A baseline of 4 is given for zero-parameter tools, as the description focuses on the tool's purpose without unnecessary parameter clutter.
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: 'Returns the current solana versions running on the node.' It specifies the verb ('returns') and resource ('current solana versions'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'get_identity' or 'get_cluster_nodes', which might also return node-related information, 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 any context, prerequisites, or exclusions, and with many sibling tools (e.g., 'get_identity' for node identity or 'get_cluster_nodes' for node details), there's no help in distinguishing usage scenarios. This leaves the agent to infer based on tool 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('Vote accounts information in the format "Vote accounts: {accounts}"'), which adds some context, but it doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or how the data is structured (e.g., pagination, error handling). For a tool with zero annotation coverage, 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 appropriately sized and front-loaded, with the core purpose stated clearly in the first sentence. The second sentence provides return format details, which is useful. There's no wasted text, making it efficient, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and the lack of annotations and output schema, the description is moderately complete. It explains what the tool returns and the format, but it doesn't fully compensate for missing behavioral details (e.g., safety, performance). For a no-param tool, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required, but it doesn't go beyond what's already covered by 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's purpose: 'Returns the account info and associated stake for all the voting accounts in the current bank.' It specifies the verb ('returns'), resource ('account info and associated stake'), and scope ('all the voting accounts in the current bank'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'get_account_info' or 'get_largest_accounts', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'get_account_info' and 'get_largest_accounts' that might overlap in functionality, there's no indication of context, prerequisites, or exclusions. This lack of usage guidelines leaves the agent to infer when this tool is appropriate.
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. While it mentions the tool confirms transactions and returns status, it doesn't explain what 'confirm' means operationally (e.g., does it wait for confirmation, check existing status, or trigger confirmation?), what permissions are needed, potential rate limits, or error conditions. For a tool with no annotations, 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 efficiently structured with a clear purpose statement followed by well-organized Arg and Return sections. Every sentence earns its place: the first sentence states the core purpose, and the subsequent sections provide essential parameter and return value information without redundancy. The formatting with clear section headers enhances 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 tool has 2 parameters with 0% schema description coverage and no output schema, the description does a reasonable job explaining parameter semantics but leaves gaps in behavioral context. It doesn't explain what 'transaction confirmation status' means in practice (what values might be returned, what they signify), and with no annotations, it misses important operational details like error handling or performance characteristics. The description is adequate but incomplete for a tool that interacts with transaction states.
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 description adds meaningful context for both parameters beyond the schema. For 'tx_sig', it clarifies this is the 'transaction signature to confirm' (schema only shows title 'Tx Sig'). For 'commitment', it explains this is 'Bank state to query' and provides the valid values ('finalized', 'confirmed' or 'processed'), while the schema only shows 'Commitment' with no enum constraints. With 0% schema description coverage, the description compensates well by explaining parameter purposes and valid values.
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: 'Confirm the transaction identified by the specified signature.' It specifies the verb ('confirm') and resource ('transaction'), but doesn't explicitly differentiate from sibling tools like 'get_transaction' or 'get_signature_statuses' which might provide similar transaction status information. The purpose is clear but 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. With sibling tools like 'get_transaction', 'get_signature_statuses', and 'send_transaction' available, there's no indication of when 'confirm_transaction' is the appropriate choice. The description only states what the tool does, not when to use it.
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 returns account information but doesn't describe what that includes (e.g., balance, data, owner), whether it's a read-only operation, error conditions, or performance aspects 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 front-loaded with the core purpose, followed by clear sections for Args and Returns. Each sentence earns its place by providing essential information without redundancy. The structure is efficient and easy to parse, with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameters well but lacks behavioral details (e.g., what 'account info' entails, error handling) and usage guidelines. This is adequate as a minimum viable description but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'pubkey' is the 'Pubkey of account to query' and 'encoding' specifies the format for account data with examples ('base58', 'base64', or 'jsonParsed'). This compensates well for the schema's lack of descriptions, though it doesn't detail default values or constraints.
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: 'Returns all account info for the specified public key.' It specifies the verb ('Returns') and resource ('account info'), and distinguishes it from siblings like get_balance (which returns only balance) and get_multiple_accounts (which handles multiple accounts). However, it doesn't explicitly contrast with all similar siblings, keeping it at 4 rather than 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 siblings like get_balance (for just balance) or get_multiple_accounts (for multiple accounts), nor does it specify prerequisites or exclusions. The agent must infer usage from the purpose 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 the return format ('Epoch information in the format "Epoch info: {info}"'), which adds some context beyond the basic purpose. However, it lacks details on potential errors, rate limits, network dependencies, or what 'current epoch' entails in this context, making it insufficient for a mutation-free but context-sensitive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise return format specification. Every sentence earns its place without redundancy, making it efficiently structured 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 annotations, no output schema), the description is reasonably complete for a basic read operation. It covers purpose and return format. However, without annotations or output schema, it could benefit from more behavioral context (e.g., what 'epoch' means here, error cases), but it's adequate for minimal complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param details, which is appropriate. It slightly exceeds the baseline by including return format info, but since there are no params, a score of 4 reflects that it adequately addresses the minimal requirement.
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: 'Returns information about the current epoch.' This is a specific verb ('Returns') and resource ('information about the current epoch'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like get_epoch_schedule, which might provide related but different epoch data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like get_epoch_schedule, get_slot, and get_block_height that might offer related temporal or epoch data, there's no indication of context, prerequisites, or exclusions. This leaves the agent without 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 return format ('str: Current slot in the format "Current slot: {slot}"'), which adds some context, but it doesn't cover other important aspects like whether this is a read-only operation, potential errors, or performance characteristics. For a tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, using two brief sentences that directly state the purpose and return format without any wasted words. It's front-loaded with the core functionality, 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.
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 has gaps. It explains the return format, which is helpful, but lacks behavioral context (e.g., safety, errors) and usage guidelines relative to siblings. For a basic read operation, it's minimally viable but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it appropriately focuses on the return value. This meets the baseline for tools with no parameters, as there's nothing to compensate for.
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 ('Returns') and resource ('current slot the node is processing'), making it easy to understand what it does. However, it doesn't explicitly distinguish itself from sibling tools like 'get_minimum_ledger_slot' or 'get_slot_leader', which also deal with slots, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other slot-related tools in the sibling list. It lacks context about scenarios where this tool is appropriate, prerequisites, or exclusions, leaving the agent to infer usage based on 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 the return format ('str: Slot leader in the format "Slot leader: {leader}"'), which adds some context beyond the basic purpose. However, it lacks details on critical behaviors like whether this is a read-only operation, potential rate limits, authentication needs, or error conditions, leaving significant gaps for a tool with no annotation support.
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 and well-structured. It uses two sentences: the first states the purpose, and the second specifies the return format. Every sentence adds value without redundancy, making it front-loaded and efficient for quick understanding by an AI agent.
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 has clear gaps. It covers the purpose and return format, which is sufficient for basic use. However, without annotations or output schema, it lacks details on behavioral traits like safety or error handling, making it minimally viable but not fully comprehensive for operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline score of 4 is applied as it meets the requirement for zero-parameter tools by not introducing unnecessary details.
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: 'Returns the current slot leader.' It specifies the verb ('returns') and resource ('current slot leader'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_leader_schedule' or 'get_slot', which provide related but distinct information about leadership or slot data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, such as when to prefer 'get_leader_schedule' for broader leadership data or 'get_slot' for slot numbers. This lack of usage instructions leaves the agent to infer appropriate scenarios 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 the full burden of behavioral disclosure. It states the tool returns supply information in a specific string format, which is helpful. However, it lacks details on potential side effects, error conditions, rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: it states the purpose in one sentence and the return format in another. Every sentence adds value—the first explains what the tool does, and the second clarifies the output format. There's no wasted text or redundancy.
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 has clear gaps. It explains the purpose and return format, which is sufficient for basic use. However, without annotations or output schema, it lacks details on error handling, side effects, or how it differs from similar tools like 'get_token_supply', reducing completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters, so it meets baseline expectations. No additional parameter semantics are required, but it doesn't go beyond the schema (which is fine given no parameters).
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: 'Returns information about the current supply.' This specifies the verb ('returns') and resource ('current supply'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_token_supply' or other supply-related tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'get_token_supply', 'get_balance'), there's no indication of context, prerequisites, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal 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. It states the tool returns details for 'confirmed' transactions, which is a useful behavioral constraint. However, it lacks information on error handling (e.g., if the hash is invalid or transaction is unconfirmed), rate limits, authentication needs, or the format of returned details beyond a vague string. 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured 'Args' and 'Returns' sections. Every sentence adds value, with no redundant or vague language. The structure enhances readability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics well but lacks usage guidelines and sufficient behavioral context (e.g., error cases, output details). For a read operation with no annotations, more guidance on behavior would improve completeness.
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 description adds meaningful semantics beyond the input schema. The schema has 0% description coverage, only indicating 'hash' is a required string. The description specifies that 'hash' is a 'Transaction signature as base-58 encoded string', clarifying the parameter's purpose and format. This compensates well for the low schema coverage, though it doesn't detail validation rules or examples.
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: 'Returns transaction details for a confirmed transaction.' It specifies the verb ('returns') and resource ('transaction details'), distinguishing it from siblings like 'confirm_transaction' or 'get_transaction_count'. However, it doesn't explicitly differentiate from 'get_signatures_for_address' or 'get_signature_statuses', which might also relate to 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 prerequisites (e.g., transaction must be confirmed), exclusions, or comparisons to sibling tools like 'get_signature_statuses' or 'get_transaction_count'. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a connection status string, but lacks details on error handling, latency, side effects, or authentication needs. For a health-check tool with zero annotation coverage, this is a moderate gap, as it doesn't fully describe operational behavior beyond the basic output.
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 the first sentence stating the purpose clearly. The second sentence explains the return format, which is useful. There is no wasted text, and it efficiently conveys essential information in two 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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is somewhat complete but could be improved. It covers the purpose and return format, but lacks context on when to use it, error scenarios, or integration with sibling tools. For a simple health-check, this is adequate but has clear gaps in guidance and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there is no need for parameter documentation in the description. The baseline for such cases is 4, as the description appropriately omits parameter details, focusing instead on the tool's purpose and output.
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 as a 'Health check to verify if the client is connected,' which is a specific verb ('verify') and resource ('client connection'). It distinguishes itself from sibling tools that mostly retrieve blockchain data or perform transactions, though it doesn't explicitly contrast with them. The purpose is not tautological with the name 'is_connected' and is straightforward.
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 connection status, likely as a preliminary step before other operations, but does not explicitly state when to use it versus alternatives. There is no mention of prerequisites, exclusions, or specific contexts. This leaves some ambiguity, though the health-check nature suggests general applicability.
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 states the tool returns a balance, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, or details error conditions. The return format is described, which adds some context, but lacks information on network behavior or potential 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?
The description is well-structured and front-loaded with the core purpose, followed by clear 'Args' and 'Returns' sections. Every sentence adds value: the first states what the tool does, the second explains the parameter, and the third specifies the return format. No redundant or verbose language is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic completeness for a simple query tool. It covers the purpose, parameter meaning, and return format, but lacks details on error handling, network behavior, or performance considerations. For a balance-checking tool in a blockchain context, this is adequate but leaves gaps an agent might need to infer.
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 description coverage is 0%, so the description must compensate. It explains the single parameter 'address' as 'Pubkey of account to query,' clarifying that it's a public key string for account identification. This adds meaningful semantics beyond the schema's generic 'Address' title and 'string' type, though it doesn't detail format constraints or examples.
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: 'Returns the balance of the account of provided Pubkey.' It specifies the verb ('returns') and resource ('balance'), distinguishing it from siblings like 'get_account_info' (which likely returns more comprehensive account data) or 'get_token_account_balance' (which focuses on token-specific balances). However, it doesn't explicitly contrast with these alternatives in the description text itself.
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 siblings like 'get_account_info' (which might include balance plus other info) or 'get_token_account_balance' (for token accounts), nor does it specify prerequisites or exclusions. The agent must infer usage from the purpose 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 the tool returns the current block height and the return format, but lacks information about potential errors, rate limits, authentication requirements, or whether it's a read-only operation (though implied by 'Returns'). For a tool with zero annotation coverage, 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 appropriately concise with two sentences: one stating the purpose and one detailing the return format. It's front-loaded with the core functionality. The structure is clear, though the 'Returns:' label could be slightly more integrated.
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 has no parameters and no output schema, the description covers the basic purpose and return format adequately. However, it lacks context about behavioral aspects like error conditions or performance, which would be helpful for a tool in a blockchain context where nodes might be unavailable or slow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though trivial with no parameters). The description doesn't need to explain parameters, so it appropriately focuses on the return value. It adds value by specifying the return format, which isn't covered by the schema since there's no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('current block height of the node'), distinguishing it from siblings like get_block, get_blocks, get_block_time, and get_slot which return different blockchain data. It precisely defines what the tool does without ambiguity.
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 that return related blockchain data (e.g., get_block, get_slot, get_minimum_ledger_slot), there is no indication of when this specific tool is appropriate or what distinguishes it from similar tools in the server.
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 states the return type ('str') and format ('Epoch schedule: {schedule}'), which adds useful context beyond the basic purpose. However, it doesn't cover potential errors, latency, or other operational traits like rate limits or authentication needs, leaving gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It uses two sentences: the first states the purpose clearly, and the second specifies the return format. Every sentence adds value without redundancy, and it's front-loaded with the core functionality. No wasted words or unnecessary details.
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 (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does and the return format, which is sufficient for basic use. However, without annotations or output schema, it lacks details on error handling, performance, or deeper behavioral context, making it minimally viable but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, and it appropriately avoids discussing inputs. A baseline of 4 is applied as per the rules for tools with zero parameters, as there's no gap to compensate for.
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: 'Returns epoch schedule information from this cluster's genesis config.' It specifies the verb ('Returns'), resource ('epoch schedule information'), and source ('from this cluster's genesis config'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'get_epoch_info', which provides related but different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_epoch_info' or explain scenarios where this specific schedule information is needed over other epoch-related data. Usage is implied by the purpose but lacks explicit context 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?
No annotations are provided, so the description carries full burden. It states the tool returns exactly 20 accounts and the output format, but lacks details on permissions, rate limits, error conditions, or whether this is a read-only operation. For a query tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The Args/Returns sections are structured but slightly verbose (e.g., repeating 'Largest token accounts' in the return). Every sentence adds value, though minor trimming is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description provides basic purpose and parameter semantics but lacks behavioral context (e.g., safety, limits) and detailed usage guidelines. It's adequate for a simple query tool but incomplete for robust agent decision-making.
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 description coverage is 0%, but the description compensates by explaining the 'mint' parameter as 'Pubkey of token mint to query'. This adds meaning beyond the schema's generic 'Mint' title. With only one parameter, the description adequately clarifies its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Returns') and resource ('20 largest accounts of a particular SPL Token type'). It distinguishes from siblings like 'get_largest_accounts' (general) and 'get_token_accounts_by_owner' (owner-specific) by focusing on token mint-based ranking.
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 explicit guidance on when to use this tool versus alternatives like 'get_token_accounts_by_owner' or 'get_token_supply'. The description implies usage for token mint queries but lacks context on prerequisites, exclusions, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns information about a 'confirmed block', which hints at read-only behavior, but does not disclose other traits like error handling, rate limits, or whether it requires specific permissions. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured clearly without unnecessary details, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving block data), no annotations, no output schema, and 0% schema coverage, the description is somewhat complete but lacks details on output format beyond a string example, error cases, or behavioral constraints. It meets minimum viability but has clear gaps for full agent understanding.
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 description adds meaning beyond the input schema by explaining that 'slot' is a 'Slot number as u64 integer', clarifying the data type and format. With 0% schema description coverage and only 1 parameter, this compensates well, though it could provide more context on valid slot ranges or examples.
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 ('Returns') and resource ('identity and transaction information about a confirmed block in the ledger'), making the purpose specific. It distinguishes from siblings like 'get_blocks' (plural) and 'get_block_time' by specifying it returns block information rather than multiple blocks or timing data.
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 retrieving block details by slot number, but does not explicitly state when to use this tool versus alternatives like 'get_blocks' or 'get_block_commitment'. No exclusions or prerequisites are mentioned, leaving usage context partially inferred.
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 return format ('Transaction count: {count}') which is helpful, but doesn't mention whether this is a read-only operation, if it requires authentication, potential rate limits, or what 'current' means in terms of data freshness. For a tool with zero annotation coverage, this leaves significant behavioral aspects undocumented.
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 perfectly concise with two sentences that each earn their place: the first states the core purpose, and the second clarifies the return format. There's zero wasted text, and the information is front-loaded with the most important detail first. The structure is logical and efficient.
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 that this is a simple read operation with 0 parameters and no output schema, the description provides the essential purpose and return format. However, with no annotations and no output schema, it should ideally mention more about the behavioral context (like whether this is a safe read operation, data freshness, or any limitations). The description is adequate but has clear gaps in contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. This meets the baseline expectation for a zero-parameter tool, though it doesn't go beyond that 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 specific action ('Returns') and resource ('current Transaction count from the ledger'), distinguishing it from siblings like get_transaction (which retrieves details of a specific transaction) or get_balance (which returns account balances). It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the phrase 'current Transaction count from the ledger', suggesting this tool is for retrieving aggregate transaction metrics rather than individual transaction details. However, it doesn't explicitly state when to use this versus alternatives like get_transaction or get_blocks, nor does it mention any prerequisites or exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Returns'), but lacks details on permissions, rate limits, error conditions, or whether it's idempotent. For a query tool with zero annotation coverage, this leaves 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 efficiently structured with a clear purpose statement, followed by Args and Returns sections. Every sentence adds value—no redundancy or fluff. It's appropriately sized for a simple query tool.
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 single-parameter query tool with no output schema, the description is reasonably complete: it explains the purpose, parameter, and return format. However, it lacks behavioral details (e.g., error handling) that would be helpful given no annotations, slightly reducing completeness.
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 description adds meaningful context for the single parameter: 'token_account (str): Pubkey of Token account to query.' With 0% schema description coverage, this compensates well by explaining the parameter's purpose and format (Pubkey). However, it doesn't specify validation rules or examples.
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: 'Returns the token balance of an SPL Token account.' It specifies the verb ('Returns'), resource ('token balance'), and target ('SPL Token account'), distinguishing it from siblings like get_balance (likely native SOL balance) and get_token_accounts_by_owner (list of accounts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'SPL Token account,' suggesting it's for token balances rather than native SOL. However, it doesn't explicitly state when to use this vs. alternatives like get_balance or get_token_accounts_by_owner, nor does it mention prerequisites or 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 carries the full burden. It discloses that the tool returns a string in a specific format, which is useful behavioral context. However, it lacks details on potential errors, latency, or side effects (e.g., if this is a read-only operation, though implied by 'Returns').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by return format details. Both sentences are essential, with zero waste, making it highly concise and well-structured for a simple tool.
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 (0 parameters, no annotations, no output schema), the description is complete enough by stating what it returns and the format. It could improve by mentioning if it's read-only or has any constraints, but for a basic identity fetch, it covers the essentials adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics beyond the schema, but with no parameters, a baseline of 4 is appropriate as there is no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('identity pubkey for the current node'), and it distinguishes from siblings by focusing on node identity rather than account, block, or transaction data. The description explicitly mentions the return format, which adds clarity.
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 when the node's identity is needed, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., other 'get_' tools for different data). No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
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 clearly describes the return format and that this is a read operation, but doesn't mention potential rate limits, network dependencies, or what happens if the ledger is unavailable. For a zero-parameter read tool, this provides adequate but minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second specifies the exact return format. No wasted words, front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool with no output schema, the description provides the essential information: what it does and the exact return format. It could potentially mention that this is a common prerequisite for transaction construction, but given the tool's simplicity and lack of annotations/output schema, it's reasonably complete.
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the return value. No parameter information is needed or expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Returns') and resource ('latest block hash from the ledger'), distinguishing it from sibling tools like get_block (which returns full block data) or get_block_height (which returns height rather than hash). The verb+resource combination is precise 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the return format specification, suggesting this is for obtaining the most recent blockhash. However, it doesn't explicitly state when to use this versus alternatives like get_block (for full block data) or get_genesis_hash (for the initial blockhash). No explicit when/when-not guidance is provided.
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:

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

Score Badge

Copy to your README.md:

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

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/tywenk/mcp-sol'

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