VeChain AI Terminal MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation1/5
Multiple tools have overlapping functionality, e.g., nft_get_transfer_history and vechainstats_get_nft_transfers both retrieve NFT transfer history, and get_token_info vs vechainstats_get_token_info are nearly identical. The sheer number of similar getters makes it difficult for an agent to select the correct tool.
Naming Consistency2/5
Naming is inconsistent: some tools use a namespace prefix (vechainstats_, nft_, bridge_), others are bare verbs (stake_vet, sign_message, transfer_vet). No uniform verb_noun pattern, and similar operations are named differently across domains (e.g., get_user_stakes vs nft_get_owned_tokens).
Tool Count1/5
With 92 tools, the server is dramatically over-scoped for a coherent toolkit. This is far beyond the typical 3-15 well-chosen tools and even exceeds the 25+ threshold for a heavy set.
Completeness3/5
The server covers many domains (stats, NFT, DEX, bridge, wallet, VeBetter), but each domain has gaps. For example, NFT operations lack metadata updates, and VeBetter lacks submission status or cancellation. The extraordinary breadth means depth suffers, leaving some workflows incomplete.
Average 3.3/5 across 92 of 92 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only says 'Get information' with no details on return format, side effects, read-only nature, or error handling. This gives the agent no insight into what the tool actually does beyond the implied get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and thus concise, but it is under-specified and merely expands the tool name without adding value. The sentence does not earn its place because it repeats information already contained in the tool name, lacking any substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a description that provides no information about return values, usage examples, or behavior. An agent cannot determine what data will be returned or how to handle the response. This is extremely incomplete for even a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter 'appId', described as 'VeBetter App ID'. The description does not add further meaning to this parameter, but the schema already provides sufficient semantic context. Since schema coverage is complete, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about a VeBetter app' essentially restates the tool name 'vebetter_get_app_info' without adding any specificity about what 'information' entails. It does not differentiate from other get-type tools beyond naming the resource, which is already present in the tool name. This borders on tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (like having an appId), what scenarios call for this tool, or any exclusions. There is no context distinguishing it from sibling tools that also retrieve data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It is a read-only operation by implication, but it does not disclose any specifics such as required network connection, potential latency, or what data fields are returned. No behavioral traits are revealed beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is concise. However, it is under-specified: it omits essential detail about what 'information' is provided, making it less helpful than a concise but complete statement would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should clearly define what the tool returns. It does not mention the type of information, the response format, or any edge cases. A more complete description like 'Returns the chain ID, network name, and latest block number' would be far more suitable.
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?
There are zero parameters, and the schema description coverage is vacuously 100%. The baseline for 0 parameters is 4, and the description does not need to explain parameter semantics. It adds nothing beyond the schema, but that is acceptable since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get information about the connected blockchain' but does not specify what information it returns (e.g., chain ID, network name, block height). The verb+resource pattern is present, but the purpose is too vague to distinguish it from many sibling tools that also retrieve blockchain-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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclusions, leaving the agent without context on when this should be called.
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, the description carries the full burden of behavioral disclosure. It only states that the tool 'gets' statistics for a timeframe, but does not disclose what data is returned, whether it is aggregated or per-block, any rate limits, or how timeframes are interpreted. This is minimal and insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It efficiently states the action and scope, making it highly concise. While more content would be helpful, the structure itself is ideal.
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 has no output schema, no annotations, and many sibling tools offering similar functionality, the description is excessively sparse. It does not explain what 'network statistics' includes, what the response looks like, or how it differs from related tools, leaving the agent without critical context for correct selection and 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 schema covers 100% of the parameter (timeframe) with a clear format description. The description's phrase 'specific timeframe' adds no extra meaning beyond the schema, earning the baseline score of 3. No additional parameter context is provided.
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 uses a clear verb+resource structure ('Get network statistics') with a timeframe qualifier, but 'network statistics' is vague and overlaps with sibling tools like vechainstats_get_network_totals and vechainstats_get_network_emissions. It does not specify what metrics are included, making it hard to distinguish from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or specific scenarios where this tool is preferred over other network-related tools, leaving the agent to guess.
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 disclosing behavioral traits. It only states the action ('get') and resource, giving no details about return format, error handling, or behavior when the contract is not verified. This lack of behavioral transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that is front-loaded with the verb. It is appropriately sized for the tool's apparent simplicity, containing no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide complete context. It does not explain the return value format, how 'expanded' modifies results, or any failure scenarios. Given the undocumented parameter and missing behavioral details, the description is inadequate for an agent to fully understand the tool's usage.
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?
The input schema describes only the 'address' parameter (50% coverage), leaving 'expanded' undocumented. The description adds no information about either parameter, failing to clarify the purpose or effect of the boolean 'expanded' flag. With schema coverage not high, the description should have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get verified contract source code' uses a clear verb ('Get') and a specific resource ('verified contract source code'), distinguishing it from sibling tools like vechainstats_get_contract_info which likely returns metadata. However, it does not explicitly contrast with alternatives or mention the Vechain network, so it falls short of 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 alternative tools. It does not mention prerequisites (e.g., contract must be verified), alternatives, or exclusions. Users are left to infer usage solely from the tool name and description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It merely states the informational content and implies a read operation via 'Get', but does not disclose side effects, permission requirements, rate limits, or response format. This leaves the agent with significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundancy. It front-loads the core purpose and specific data fields, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for the tool's complexity: it fails to explain the 'expanded' parameter, offers no return-value details (no output schema exists), and does not disambiguate from similar NFT tools in the sibling list. Given these gaps, the description is insufficient for an agent to choose and invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: the 'id' parameter is described in the schema, but 'expanded' has no description and the tool description does not explain it. The description mentions outputs but not input semantics, particularly for the undocumented boolean parameter, which is a clear gap.
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 uses a specific verb ('Get') and resource ('NFT collection information') and lists concrete data points (floor price, volume, holder count). However, it does not differentiate from the sibling tool nft_get_collection_info, which likely serves a similar purpose.
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?
There is no guidance on when to use this tool versus alternatives. No mention of use cases, exclusions, or preferred contexts. The description simply states what it does without any strategic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Claim accumulated VTHO rewards for a StarGate NFT'. It does not disclose that this is likely an on-chain transaction requiring gas/signature, that it is irreversible, or what the response contains. The description carries the full burden and falls short for an action-oriented 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 one concise sentence with no redundant words. It is front-loaded with the verb 'Claim' and clearly states the object and target, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing claim operation with no annotations, no output schema, and minimal context, the description is incomplete. It omits crucial information such as what the tool returns (e.g., transaction hash), prerequisites like maturity or ownership, and potential side effects. This lack of context makes it harder for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'tokenId' as 'StarGate NFT token ID to claim rewards for'. The description adds no extra meaning beyond the schema, but since schema coverage is 100%, a baseline 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 uses a specific verb 'Claim' and identifies the resource 'accumulated VTHO rewards' for a 'StarGate NFT'. This clearly communicates the tool's function, but it does not explicitly differentiate it from sibling tools like vechainstats_get_account_vtho_info or unstake_stargate_nft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as NFT ownership, maturity period, or whether rewards must be accumulated, nor does it reference related tools like is_under_maturity_period or get_maturity_end_block.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 simply restates the tool's name ('Get detailed information') and offers no information about side effects, safety (e.g., read-only nature), required permissions, error cases, or return format. This is essentially a tautology and provides zero transparency beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. It has no wasted words. However, it is almost identical to the tool name, so while efficient, it doesn't add much value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an info-retrieval tool with no output schema and no annotations, the description is quite sparse. It does not specify what 'detailed information' includes (e.g., name, symbol, total supply, floor price), nor does it clarify the distinction from nft_get_metadata or vechainstats_get_nft_info. The description is minimally adequate for a simple get tool but lacks the depth needed for an agent to confidently choose it among many similar NFT 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 schema already provides 100% coverage of the single parameter, collectionId, with a clear description ('NFT collection ID or contract address'). The description adds no additional meaning or context about the parameter. Given the high schema coverage, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about an NFT collection' clearly states the action (get) and the resource (detailed information about an NFT collection). It distinguishes from sibling tools like nft_get_owned_tokens (tokens owned by a user), nft_get_metadata (metadata for a specific token), and vechainstats_get_nft_info (NFT-level info) by focusing on the collection-level scope.
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. There is no mention of scenarios where this tool is preferred over nft_get_all_collections, nft_get_metadata, or vechainstats_get_nft_info, nor any exclusions. The agent is left 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. It mentions an external dependency (VeChainStats) but omits important behavioral traits such as pagination behavior, return format, potential rate limits, or whether the history is restricted to a specific network. The verb 'get' implies a read-only operation, but richer context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and scope. Every word contributes value, and there is no unnecessary detail or repetition.
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 output schema and annotations, the description should explain more about return values, pagination, or usage constraints. It does not mention what the transfer history contains, how pages work, or how this tool relates to sibling tools. This is a minimal description that leaves out key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since both parameters ('address' and 'page') have descriptive text. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get NFT transfer history for an address'. It is specific and action-oriented. However, it does not differentiate from the closely named sibling tool 'vechainstats_get_nft_transfers', which likely serves a similar or overlapping purpose.
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?
There is no guidance on when to use this tool versus alternatives such as vechainstats_get_nft_transfers or nft_get_owned_tokens. The note 'uses VeChainStats' hints at an external dependency but does not clarify the intended use case or how it differs from similar tools.
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 does not mention any constraints (e.g., date must be historical), the effect of the 'expanded' parameter, or the shape of the response. As a read tool it likely doesn't have side effects, but the description provides no details beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. The trailing 'etc.' is slightly vague but the overall structure is efficient. Every word earns its place, though more precision could be added without bloat.
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?
With no output schema and no annotations, the description should explain what data is returned, any date range limitations, and how 'expanded' changes the response. It does none of that. For a data-returning tool with these gaps, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'date' and 'expanded' are already documented in the schema. The description adds example stats (new accounts, active accounts) but does not add any parameter-specific meaning beyond what the schema provides. Baseline 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 'Get daily statistics for accounts' with examples of the statistics (new accounts, active accounts). This is a specific verb+resource, but it doesn't explicitly differentiate from sibling tools like vechainstats_get_block_daily_stats or vechainstats_get_network_stats, though the name 'account' provides some 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. There are no explicit when-to-use or when-not-to-use statements, and no mention of alternatives. The description simply states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'detailed information' without specifying what fields are returned, whether any permissions are needed, or any quirks. It adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence with no filler, making it easy to parse. It could be more informative without sacrificing brevity, but as written it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool, the description conveys the core purpose, but it does not describe return values or usage context, and there is no output schema to fill the gap. This is adequate but leaves the agent uncertain about what 'detailed information' will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter blocknum as 'Block number' (100% coverage), so the baseline applies. The description adds no additional parameter semantics, but none are needed given the complete 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 identifies a clear action (get detailed information) and resource (a specific block), and the required blocknum parameter in the schema clarifies that it is block-number-based. However, it doesn't explicitly distinguish from sibling tools like get_block_by_timestamp or get_block_by_reference, leaving differentiation to the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives. The description doesn't mention that it should be used when a block number is known or exclude the timestamp/reference variants.
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 disclosing behavioral traits. It does not mention that this is a read-only operation, nor does it describe pagination, sorting behavior, response format, or rate limits. This is a significant gap for a data-fetching 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 a single, clear, front-loaded sentence that communicates the core purpose without wasted words. It is appropriately concise for a tool whose nuances are mostly captured in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no output schema, and no annotations. The description fails to mention important behavioral context such as pagination, sort options, response contents, or that it is a read-only call. This leaves the agent under-informed for using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; all three parameters (address, page, sort) have descriptive entries in the schema. The tool description adds no additional meaning beyond what the schema already provides, so it does not exceed the baseline of 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 states a specific verb ('Get') and resource ('NFT transfer history') with a clear scope ('for an address'). However, it does not explicitly differentiate from sibling tools like nft_get_transfer_history or vechainstats_get_token_transfers, so it falls short of 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, nor does it mention any prerequisites, exclusions, or complementary tools. It simply states what the tool does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Get' implying a read-only operation, but provides no detail on response format, pagination, time ranges, or potential errors. The behavior is minimal and undisclosed beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it essentially restates the tool name without adding explanatory value. It is not overly verbose, but it also does not earn its place beyond labeling the operation. Adequate but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and no annotations, so the description is the only source of contextual information. 'Node token statistics' is ambiguous and could be confused with other node or token stats tools. The description does not clarify what data is returned, making it incomplete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. Per the rubric, a 0-parameter tool receives a baseline of 4, and the description does not need to add parameter semantics. It adds nothing, but nothing is missing.
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 uses a specific verb 'Get' and a resource 'VeChain node token statistics', which is reasonably distinct. However, it does not explain what these statistics contain or how they differ from sibling tools like get_authority_nodes or get_xnode_list, so it is clear but not fully differentiating.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention any context, 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 full responsibility for disclosing behavior. It only states the action and object, adding no context about confirmation details, return format, potential errors, or whether the transaction may be pending. This lack of transparency limits the agent's ability to anticipate the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word earns its place, with no redundant or unnecessary content.
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, output schema, and the presence of a possibly overlapping sibling tool, the description is minimal. It fails to explain what 'confirmation info' includes, when to use this tool, or how it differs from similar tools, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'txid' as 'Transaction ID (hash)', providing complete coverage. The description adds no additional parameter semantics, but since schema coverage is 100%, 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 uses a specific verb ('Get') and names the resource ('transaction status and confirmation info'), making it clear what the tool returns. However, it does not distinguish itself from the sibling tool 'vechainstats_get_transaction_info', which might overlap in 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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The sibling tools like 'vechainstats_get_transaction_info' suggest possible overlap, but the description does not clarify when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'build cross-chain swap transaction' without explaining whether this constructs an unsigned transaction, executes a swap, or requires prior approvals. It does not mention side effects, return format, or any safety-related traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise. However, the parenthetical '(section 5)' is vague and may confuse rather than help, slightly diminishing the structural quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no output schema, and non-trivial behavior (cross-chain swap transaction building), the description is not complete. It lacks any indication of the return value, prerequisites, or behavioral context, making it insufficient for an agent to understand the tool's full role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for every parameter, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, but it also does not need to compensate for missing schema 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?
Description clearly states the tool 'builds a cross-chain swap transaction using XFlows', which is a specific verb and resource. The mention of XFlows helps distinguish it from sibling tools like bridge_create_transaction, but the reference to 'section 5' is cryptic and adds little 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?
No guidance is provided on when to use this tool vs alternatives such as xflows_get_quote or bridge_create_transaction. No prerequisites, sequencing, or exclusions are mentioned, leaving the agent without context on how to select this tool appropriately.
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 responsibility. It does not disclose whether the operation is read-only, what the response includes, or any side effects. The phrase 'Get quote' implies read-only, but this is not explicit, and the reference to 'XFlows API, section 4' adds no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the action front-loaded. However, the parenthetical reference to 'XFlows API, section 4' is not meaningful to an agent and could be considered unnecessary. Overall, it is concise but not perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 10 parameters (7 required), no output schema, and no annotations. The description fails to explain what the quote returns, how to handle errors, or how it relates to xflows_build_transaction and xflows_check_status. The minimal description is inadequate for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 10 parameters, achieving 100% coverage. The description adds no additional parameter semantics, but the schema is sufficient, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get quote') and the resource ('cross-chain swap with DEX integration'). It distinguishes from simple quote tools but does not explicitly contrast with sibling tools like dex_get_swap_quote or bridge_get_quota_and_fee, so it is clear but not fully differentiating.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention call context, prerequisites, or exclusions. Only the raw purpose is given.
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 disclosure burden. It conveys that this is a read-only operation aggregating across DEXes, but it does not mention pagination behavior, sort defaults, or what the returned trade history looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear verb and object, and parenthetical examples that add useful context without excess verbosity.
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?
With no output schema and no annotations, the description should explain return shape or pagination details; it does not. The presence of a similarly named sibling and two undocumented parameters further reduces the completeness of the context provided.
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 only 33% with only 'address' described. The description itself explains address usage but leaves 'page' and 'sort' entirely undocumented in both the schema and description, providing no semantic guidance for those 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 action ('Get'), the resource ('DEX trading history for an address'), and the scope ('across all VeChain DEXes'), listing example DEXes. However, it does not explicitly differentiate from the similarly named sibling tool dex_get_trade_history.
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 is given on when to use this tool versus alternatives. The description implies broad cross-DEX usage but does not mention the closely related sibling dex_get_trade_history or any 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 present, so the description carries the full burden. It discloses the scale (300+ pairs, 25+ chains) but does not mention behaviors such as pagination, data freshness, filtering semantics, or whether the returned list is complete. For a read-only listing tool, this is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It immediately conveys the core function and a key data point, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no required parameters, no nested objects, no output schema), and the description provides the essential purpose and scale. However, in the absence of any annotations or output schema, the description could offer more context about return values or typical use cases, though the minimal design keeps it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions ('Filter by destination chain type', 'Filter by source chain type'). The description adds no parameter-specific meaning beyond what the schema already provides, so baseline 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 function: 'Get all available cross-chain token pairs' with a specific verb and resource, and provides scale context ('300+ pairs across 25+ chains'). It is distinct from most sibling tools, though it does not explicitly differentiate from the closely named 'bridge_get_token_pairs_hash'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like bridge_get_token_pairs_hash or xflows_get_supported_tokens. The description simply states what it does without explaining typical usage scenarios or when filtering by fromChain/toChain would be 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?
There are no annotations, so the description carries the full burden. It merely states the action and data source; it does not disclose any behavioral traits such as pagination, rate limits, response structure, or whether the data is real-time. For a getter, some context is expected but missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded, concise sentence that communicates the essential function and data source without 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?
For a simple one-parameter getter, the description is minimally adequate. However, since there is no output schema, it could have benefited from a brief mention of the return format or the specific data fields returned, to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a complete description of the single parameter 'address' with a default. The tool description adds no additional meaning beyond what the schema already provides, so the baseline 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 states a clear verb ('Get') and resource ('DEX trading history for an address'), with the address scope specified. It is sufficiently distinct from most siblings, though it does not explicitly differentiate from the similar vechainstats_get_dex_trades.
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 is given about when to use this tool versus alternatives like vechainstats_get_dex_trades or dex_get_swap_quote. The usage is only implied by the description: when you need DEX trade history for an address.
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 implies a read-only operation by saying 'Get balance' but does not explicitly state that it is non-mutating, has no side effects, or requires no special permissions. For a simple read tool this is a minor gap, but the description adds no behavioral depth beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the essential function with no unnecessary words. It is front-loaded 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?
The tool is simple, and the schema covers the parameters adequately. However, there is no output schema, and the description does not mention what the response format will be or that B3TR is also supported. The missing B3TR mention in the description is a notable gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (address and tokenSymbol) are already documented. The description adds no additional parameter context and even mentions only VET/VTHO while tokenSymbol supports B3TR, slightly conflicting with the schema without contradicting it outright.
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 gets VET and VTHO balances for an address, with a specific verb and resource. However, it omits B3TR, which is listed as a valid tokenSymbol in the schema, so the description is slightly incomplete and could mislead about supported tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like vechainstats_get_vip180_balance or vechainstats_get_account_vtho_info. The description gives no context on preferred use cases 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. It only states the basic read operation and does not disclose any behaviors such as error handling, return format, rate limits, or token availability. The description adds no context beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the operation and input. No wasted 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?
With no output schema, the description does not clarify what 'information' is returned, and it does not differentiate from similar token-info siblings. For a one-parameter read tool, it is adequate but leaves gaps in expected output and selection context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents tokenSymbol with examples. The description repeats the examples but adds no additional semantic meaning, so it is at baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('information about a token') with clear input scope ('by its symbol'), and gives examples. However, it does not distinguish from sibling tools like vechainstats_get_token_info or token_exists.
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?
There is no guidance on when to use this tool versus alternatives. The description only states the function, leaving the agent to infer usage. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Get example submissions', which implies a read-only operation but does not mention response format, pagination, rate limits, or any side effects. For a no-parameter tool, the risk is low, but the absence of any behavioral context leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for the tool's simplicity and does not repeat any schema or annotation 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?
Although the tool is simple with no parameters and no output schema, the description does not explain what the example submissions contain, how they are formatted, or how they might be used. There is no output schema to fill this gap, so the description alone is insufficient for a complete understanding of the tool's return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema definition reflects that with an empty properties object. Since there are no parameters to document, the baseline score is 4. The description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves example submissions for sustainable actions. The verb 'Get' and resource 'example submissions' make the function explicit. It distinguishes from the sibling 'vebetter_submit_action' which submits actions, but it does not explicitly reference that 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. It does not mention any related tools like vebetter_submit_action or vebetter_get_impact_categories, nor any prerequisites or context for use. The usage context must be inferred solely from the name and description.
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 only states a high-level action without mentioning return format, whether the block is exact or closest match, error behavior on invalid timestamps, or that it is a read-only 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 a single, front-loaded sentence with no filler or redundancy. It is appropriately minimal for a simple tool, but it loses a point because the lack of detail makes it under-specified for an agent needing behavioral 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?
With one parameter, no output schema, and no annotations, the description must compensate by explaining return values and edge cases. It fails to do so, leaving major ambiguities about what the returned block contains, how timestamps are matched, and what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter blockts clearly defined as a Unix timestamp. The tool description adds no extra parameter meaning beyond the schema, so the baseline score of 3 applies.
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 uses the specific verb 'Find' with resource 'block' and lookup criterion 'by timestamp', clearly stating the core function. It distinguishes from siblings like get_block_by_reference and get_current_block by specifying the timestamp lookup method, though it doesn't describe what block details are returned.
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 a clear use case—retrieve a block when you have a Unix timestamp—but offers no explicit guidance, alternative comparisons, or prerequisites. It leaves the agent to infer when this tool is preferred over other block-related tools.
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, the description carries the full burden of behavioral disclosure. It communicates that this is a read operation via the verb 'Get', but it does not disclose how invalid addresses are handled, potential rate limits, or what precisely is included in 'metadata'. The minimal disclosure leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It contains no filler words and immediately conveys the core purpose. It is concise without being incomplete in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. It only vaguely mentions 'verification status and metadata' without specifying return structure, and the 'expanded' parameter remains undocumented. For a tool with this level of structural support, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (address is described, expanded is not). The description does not explain what 'expanded' controls or clarify the expected address format. It mentions 'verification status and metadata' but that relates to output, not parameter semantics. The description adds no value beyond the minimal schema descriptions.
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 'Get contract information including verification status and metadata' clearly states the action (get), the resource (contract information), and specific scope (verification status and metadata). This distinguishes it from sibling tools like get_contract_code (which retrieves code) and get_token_info (which focuses on token-specific details).
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. There are no exclusions, no mention of prerequisites, and no explanation of scenarios where a sibling tool might be more appropriate. The usage context is entirely implied by the tool name.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. However, it only states the action without mentioning pagination, response format, or any side effects/limitations, which is a significant gap for a tool with a page parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly front-loaded sentence with no wasted words. It is efficient and immediately communicates the core purpose.
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 is no output schema and the tool has multiple parameters, the description is too sparse to fully inform an agent about expected return, pagination behavior, or edge cases. It does not go beyond the basic action.
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?
The description adds minimal meaning beyond the schema. It mentions 'balances' but does not explain the token parameter (symbol or address), the threshold, or the page parameter, which are already partially described in the schema but not enhanced.
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 'Get list of token holders with balances' – a specific verb and resource. It distinguishes from sibling tools like vechainstats_get_nft_holders by explicitly mentioning token holders rather than NFT holders.
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 alternative token-related tools such as token_exists or vechainstats_get_token_info. There are no exclusions or context hints, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must supply safety/behavior context; it only lists returned fields and 'current' without disclosing data source, staleness, unknown-token behavior, or expanded flag 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?
One sentence with no filler; every word adds relevant detail (current, USD, 24h change, volume).
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?
Despite simple complexity, no output schema or annotations exist, and the optional expanded parameter is undocumented. The description does not clearly differentiate from get_all_token_prices, making it incomplete for confident invocation.
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 documents token as required with examples, but expanded has no description. The description does not explain expanded, so half the parameters lack semantic guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool fetches a single token's current USD price, 24h change, and volume. The specific resource 'token price' plus 'current' distinguishes it from bulk/quotes and price history, though it does not explicitly name sibling get_all_token_prices.
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 given about when to choose this over vechainstats_get_all_token_prices or token_info. The phrase 'current' implies real-time retrieval but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It only implies a read operation via 'Get' and provides no detail about pagination behavior, sort semantics, data availability, or response format. This is inadequate for a history endpoint that accepts page and sort parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and subject, with no redundant phrases. It is appropriately sized for the core scope it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter endpoint with no output schema and no annotations, a one-line purpose is insufficient. The description omits how page and sort behave, what the response contains, and any usage constraints, making it incomplete for safe and correct invocation.
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 50%: address and tokenType have descriptions, while page and sort do not. The description reinforces the tokenType enum values (VET/VTHO/VIP-180) but does not explain pagination or sorting, leaving half the parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') and identifies both the resource ('token transfer history') and scope ('for an address'). It also names the three supported token classes (VET, VTHO, VIP-180), which differentiates it from NFT-transfer or transaction-history sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over siblings such as vechainstats_get_nft_transfers or vechainstats_get_transactions_in/out. The description states only the tool's purpose, not when it should be selected or excluded, so the agent must infer applicability.
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. However, it only states what the tool gets and does not mention failure modes, prerequisites (e.g., valid transaction), rate limits, or side effects, which is a significant gap for a read operation 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?
A single sentence that is front-loaded with the action and includes relevant details without any filler. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is minimally adequate as it names key output elements. However, without an output schema or annotations, it could be more complete by mentioning return format, error handling, or null behavior, leaving room for interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter `txid` as 'Transaction ID (hash)' with 100% coverage, so the baseline is 3. The description references output components (clauses, events, gas used) but does not add parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a resource 'detailed transaction information' and explicitly lists clauses, events, and gas used. This distinguishes it from the narrower sibling `vechainstats_get_transaction_status`, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like `vechainstats_get_transaction_status` or `vechainstats_get_transaction_emissions`. The usage context is only implied by the word 'detailed', so an agent must infer when this tool is needed.
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, the description carries full responsibility for behavioral disclosure. While 'get' implies a read-only operation, it does not state side effects, permissions, rate limits, or return format. The reference to 'section 1.2.3' is opaque and adds no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose. However, the trailing '(section 1.2.3)' is not actionable for an AI agent and slightly detracts from usefulness, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a basic sense of what is returned (quota and fees) but lacks details on the response structure or any contextual relationship to other bridge tools. Since there is no output schema, more explanation of the result would be beneficial. The complete schema coverage for parameters helps, but the overall context is still thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional semantics about parameters, merely restating that the tool returns quota and fees. It does not clarify the optional tokenPairID's role beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves bridge quota (min/max limits) and fees in a single call. It clearly distinguishes this from sibling tools like bridge_get_token_pairs or bridge_check_status, which serve different purposes, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing token pairs first), nor does it indicate that this should be called before creating a bridge transaction. The 'in one call' hint implies efficiency but is not explicit advice.
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 responsibility for behavioral disclosure. It only says 'execute a token swap,' which implies a state-changing transaction, but does not disclose gas costs, wallet authentication, irreversibility, or the role of slippage parameters. This is insufficient for a mutation 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 a single, front-loaded sentence with no superfluous words. It is concise and easy to scan.
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?
This is a complex financial transaction tool with no output schema and no annotations, yet the description is only one clause. It lacks essential context about the execution workflow, return values, and side effects, making it inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all six parameters, so the baseline is 3. The description text itself adds no parameter-specific meaning beyond what the schema already contains.
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 uses the specific verb 'Execute' and identifies the resource as 'a token swap on a VeChain DEX'. This clearly distinguishes the tool from sibling tools like dex_get_swap_quote, dex_calculate_slippage, and dex_get_trade_history, which are read-only or analysis operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as obtaining a quote first, wallet connection, or that this is an on-chain write operation unlike the read-only DEX query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden, but it only says 'get detailed information.' It does not disclose whether the operation is read-only, whether it returns stake-specific data versus general NFT metadata, or what permissions are required. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, containing no filler or redundant phrasing. It is appropriately sized for the tool's simplicity.
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?
With no output schema and no annotations, the description should clarify what 'detailed information' includes, especially given the tool's name implies stake-specific data. It fails to mention return fields, stake status, maturity, or level, and does not distinguish itself from generic NFT info tools, leaving notable gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter, tokenId, with 100% coverage. The description adds only the phrase 'by token ID,' which reinforces but does not extend schema semantics. Baseline 3 applies because the schema handles parameter meaning adequately.
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 identifies the action ('get detailed information') and the resource ('specific StarGate NFT by token ID'), which distinguishes it from list-style siblings. However, it does not explicitly differentiate from generic NFT info tools like get_nft_info or get_nft_metadata, leaving some overlap ambiguity.
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 user has a specific StarGate NFT token ID, which provides clear context. It does not mention exclusions or alternatives, such as when to prefer get_nft_info or get_user_stakes, so guidance is limited to implied 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, the description bears full responsibility for behavioral disclosure. The verb 'Get' implies a read-only operation, but there is no mention of error behavior (e.g., invalid token ID), return format, or potential null results. The description adds no context about what the level ID represents or whether the token must belong to a specific collection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is front-loaded with the action and object, making it immediately scannable.
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?
Despite the simple one-parameter tool, the description is incomplete. There is no output schema, and the description does not explain what a level ID is, its format, or what the response will contain. For a successful agent invocation, this lack of return-value context is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter, tokenId, with a description 'Token ID to get level for'. The tool description adds no additional semantic value beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Get') and resource ('level ID of a StarGate NFT'). It distinguishes itself from sibling tools like get_staking_levels (which lists levels) and get_level_supply (which queries supply for a level) by specifying it retrieves the level ID for a particular token.
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. There is no mention of prerequisites (e.g., token ownership, existence check) or scenarios where other tools like get_staking_levels would be more appropriate. The name implies a token-level lookup, but explicit usage criteria are absent.
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, the description carries the full burden for behavioral disclosure. It only says 'Check', implying a read-only operation, but it does not specify return type, error behavior, side effects, or anything about the maturity period semantics. This is a minimal disclosure, similar to the update_drive example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose without any fluff. Every word is necessary. It is appropriately sized for a simple predicate tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., a boolean), how maturity period is determined, or what happens for invalid token IDs. The context of 'maturity period' is left undefined, which could be confusing without sibling tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter (tokenId). The tool description adds no additional meaning beyond what the schema already provides ('Token ID to check if under maturity period'), so it lands at the baseline of 3. No new format, constraints, or nuances are introduced.
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 a specific action ('Check') on a specific resource ('StarGate NFT') with a specific condition ('still under maturity period'). However, it does not distinguish itself from sibling tools like get_maturity_end_block or can_transfer_stargate_nft, so it loses a point for not differentiating.
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 its usage (when you need to know maturity status), but it provides no explicit guidance on when to use this tool versus alternatives such as get_maturity_end_block or can_transfer_stargate_nft. There are no exclusions or alternative mentions, so it only meets the 'implied usage' bar.
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 fails to mention that this is an on-chain state-changing operation that may require a wallet connection, gas fees, or that it updates the NFT's operator approval. The phrase 'approve' hints at permission but does not disclose side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of 10 words. It is immediately clear and contains no redundant or speculative content, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, the description should clarify the on-chain effect and likely return value (e.g., transaction hash). It also omits important context such as ownership requirements and the typical approval-before-transfer flow. The tool may be simple, but the description remains under-specified for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—each parameter (tokenId, operator, contractAddress) has a clear description. The tool description adds no new semantic information beyond referring to 'another address' and 'specific NFT,' which the schema already covers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Approve'), identifies the resource (a specific NFT), and states the beneficiary (another address). This clearly distinguishes it from sibling tools like nft_transfer (which actually moves the NFT) and nft_mint (which creates one).
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, nor does it mention typical workflow prerequisites (e.g., that approval is often a prerequisite for a transfer by another address). It simply states what it does without any contextual usage hints.
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 disclosing behavior, but it only states the basic action. It fails to mention that ownership changes, that prior approval may be required, that the transfer is irreversible, or that the 'safe' parameter affects execution. This is a significant transparency gap for a mutating 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 a single, front-loaded sentence with zero waste. Every word contributes to identifying the tool's purpose, and it is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse for a state-changing tool. It does not explain expected return values, failure modes, ownership preconditions, or the significance of the 'safe' flag. An agent would likely need additional context to use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptive parameter explanations ('Recipient address', 'Token ID to transfer', etc.). The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Transfer') and resource ('an NFT to another address'), clearly distinguishing it from siblings like nft_burn, nft_mint, and nft_approve. It accurately captures the tool's primary action 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 like nft_approve or transfer_token. It does not mention prerequisites such as ownership or approval requirements, nor does it exclude cases where other transfer methods should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavior. It merely restates the operation without mentioning the signature output format, whether it is read-only, or any side effects like user approval requirements. For a wallet action, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, focused sentence with no filler or redundant information. It is optimally concise for the tool's simplicity.
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?
Although the tool has only one parameter, the lack of an output schema means the description should at least hint at the return value (e.g., a signature string). It also does not clarify whether signing is a safe, read-only operation or requires user interaction. With no annotations, the description is incomplete for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'message' parameter as 'Message to sign,' achieving 100% schema coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Sign a message with the wallet.' It uses a specific verb and resource, and it is distinct from sibling tools like transfer_vet or vechainstats_get_block_info. However, it lacks details on the type or scope of signing, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs. alternatives, but signing is a unique operation among siblings, so usage is implicitly clear. The description does not mention prerequisites such as wallet connection or consent, nor does it note any situations where this tool should not be used.
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 disclosing side effects. It fails to mention that this likely creates an on-chain transaction, involves fees, or requires any approval/vetting process, leaving major behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler or redundancy. It is appropriately concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a submission/write tool with 6 parameters, no output schema, and no annotations, the description omits critical context: return values, success/failure behavior, error conditions, and any setup steps. It is too sparse to be fully usable without additional clues from sibling 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 input schema provides 100% coverage with descriptions for all parameters, so the baseline of 3 is appropriate. The description adds no additional meaning beyond the schema's already explicit parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit a sustainable action') and the target ('to a VeBetter app'), with the purpose ('for rewards'). This distinctly differentiates it from sibling tools like vebetter_claim_rewards or read-only VeBetter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., checking available funds) or contrast with claim/submission-related tools like vebetter_example_submissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what data is returned, not any side effects, failure modes, permissions, or the meaning of the 'expanded' flag. For a read tool this is minimal but not misleading, so a low score is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the resource and key included data without filler. It earns its place by being brief yet informative enough to convey the core purpose.
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?
With no output schema and no annotations, the description needs to explain what the tool returns. It mentions balances and transaction count, but 'and more' is vague and does not clarify whether it includes staking, VTHO, or other account attributes. The tool is simple, but the ambiguity around 'comprehensive' and 'expanded' leaves gaps for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema for 'address' and 'expanded'. It mentions 'balances, transaction count, and more' but does not clarify what 'expanded' changes, leaving parameter semantics to the schema alone.
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 identifies the tool as retrieving 'comprehensive account information' with specific content ('balances, transaction count'), which is a specific verb+resource+scope. It implies broader coverage than sibling tools like get_balance or vechainstats_get_account_vtho_info, but does not explicitly name alternatives, so it falls just short of full differentiation.
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?
Usage context is implied by the word 'comprehensive' and the tool name, suggesting it is the general-purpose account info endpoint. However, there is no explicit guidance on when to use this tool versus specific siblings (e.g., get_balance, vechainstats_get_vip180_balance), nor any 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 lists some returned content (gas used, transaction count) but omits details like whether the data is cached, how the 'expanded' parameter changes behavior, or any permissions/rate limits. The read-only nature is implied but not explicitly stated.
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?
A single sentence that is front-loaded with the action and resource. It is appropriately brief for a simple tool, though the trailing 'etc.' is a bit vague. No filler or redundancy.
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?
With no output schema, no annotations, and one undocumented parameter, the description is insufficient for fully understanding behavior and return structure. It gives a high-level summary but leaves key specifics (e.g., exact stats included, expanded effect) to inference, making it incomplete for a tool in a large family.
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 50%: 'date' is documented, but 'expanded' has no description. The tool description does not explain what 'expanded' controls, so parameter semantics are incomplete. The description adds no value beyond the date field already defined in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Get' + 'daily block statistics', with examples of content (gas used, transaction count). The 'daily' qualifier distinguishes it from sibling tools like get_block_info (specific block) and get_network_stats (network-wide), so the purpose is specific and non-misleading.
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 the use case: when you need daily aggregate block statistics for a given date. However, it does not explicitly state when to use this tool over alternatives like get_block_info or get_network_stats, nor are there any exclusions or alternative references.
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, the description carries the full burden for behavioral disclosure. It only states that the tool gets a list, without mentioning pagination, result limits, response format, rate limits, or whether the list is fully exhaustive in a single call. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It contains no redundant words or filler, and every word adds value.
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-only list, the description is minimally viable but lacks important contextual details such as the shape of the returned data, whether pagination is required, and how it differs from the similarly named 'nft_get_all_collections'. Given no output schema or annotations, some additional context 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 tool accepts zero parameters, so there are no parameter semantics to clarify. The input schema is empty and schema description coverage is 100%, leaving no ambiguity. The baseline of 4 applies for a zero-parameter 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 function: retrieving the list of all NFT collections on VeChain. It uses a specific verb and resource. However, it does not distinguish this tool from the similarly named sibling tool 'nft_get_all_collections', which likely serves the same purpose.
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 context about when to use this tool versus alternatives like 'nft_get_all_collections', 'vechainstats_get_nft_info', or 'vechainstats_get_nft_transfers'. There is no guidance on use cases, exclusions, or preference over other NFT-related tools.
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 only states 'Get carbon emissions' without clarifying return format, required parameter combinations, whether the operation is read-only, or any limitations. For a tool with no safety 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is appropriately concise for the tool's simplicity, though the brevity contributes to the completeness gap in other dimensions.
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?
This tool has no output schema, so the description should clarify return values (e.g., emissions amount, units). It also does not explain parameter combinations, such as whether txid alone is sufficient or if blocknum/timeframe are alternatives. Given the optional parameters and multiple sibling emission tools, this description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a brief description (txid, address, blocknum, timeframe). The description adds no additional semantics beyond 'specific transaction'. The baseline of 3 is appropriate since the schema carries the parameter documentation burden.
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 'Get carbon emissions for a specific transaction' uses a specific verb and resource, clearly identifying the tool's purpose. It distinguishes itself from sibling emission tools like get_address_emissions and get_network_emissions by specifying transaction-level granularity.
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 given on when to use this tool versus alternatives. It does not mention that address/network emission tools exist, nor does it state under what conditions this tool is preferred. The description implies transaction-level queries but provides no explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Get', implying a read operation, but does not mention error handling, authentication requirements, rate limits, or what happens if the address or contract is invalid. The description adds minimal behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that communicates the core function efficiently. Every word contributes to understanding the tool's purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only a minimal description. It does not explain what the tool returns (e.g., raw integer vs. formatted balance), the behavior when the 'contract' parameter is omitted (it is optional, so presumably a default token is used), or what 'expanded details' includes. This leaves significant gaps for an agent deciding how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description does not add additional meaning beyond the schema; it references 'token contract' in the text but provides no new parameter-level insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('VIP-180 token balance'), and the scope ('for a specific address and token contract'). This distinguishes it from sibling tools like vechainstats_get_historic_balance (which retrieves historical balances) and vechainstats_get_account_info (which provides account details).
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, nor any exclusions or prerequisites. For instance, it is not noted whether this tool is for VIP-180 tokens only and whether other tools should be used for native VET balance or other token standards.
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 only states 'check status', implying a read-only operation, but does not disclose any behavioral traits such as return format, error handling, or rate limits. Minimal value beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. It immediately states the action and resource, achieving high 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?
No output schema exists, so the description should explain return values or status outcomes. It does not. The reference to 'section 6' is cryptic and unhelpful. For a simple tool, this is still incomplete for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the parameter 'hash' is documented with 'Transaction hash to check status for'. The tool description adds no extra parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Check') and resource ('XFlows cross-chain swap status'). It distinguishes from siblings like bridge_check_status, which checks a different protocol (bridge), and vechainstats_get_transaction_status, which is not cross-chain swap specific.
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 such as bridge_check_status or vechainstats_get_transaction_status. There is no mention of prerequisites, typical use cases, 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 must disclose behavioral traits. It only says 'Get all...' which implies a read-only operation, but doesn't state whether the result is an array, whether empty results are possible, or any error/edge-case behavior. There is no added context beyond the core purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and target. There is no wasted text or redundant repetition of schema 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?
For a simple one-parameter getter, the description is adequate but minimal. There is no output schema, so the return format (e.g., an array of token IDs) is only implicit. It also omits any mention of the StarGate contract or chain, leaving some ambiguity for an agent selecting this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'address' is described in the schema. The tool description adds no new meaning beyond 'owned by an address,' so it neither compensates nor hinders. The baseline 3 applies.
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 a specific action ('Get all StarGate NFT token IDs') and the target resource ('owned by an address'). It distinguishes itself from generic siblings like nft_get_owned_tokens by specifying the StarGate NFT collection.
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 gives no guidance on when to prefer this tool over alternatives. It does not mention exclusions, prerequisites, or differences between this and similar ownership-checking tools such as nft_check_ownership or nft_get_owned_tokens.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. 'Check who owns' clearly implies a read-only operation, and the schema identifies the required inputs. However, it does not disclose the exact return format (e.g., owner address), potential edge cases (e.g., burned tokens), or any side effects. This is minimal but not misleading, earning a 3.
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 one short sentence that directly conveys the tool's purpose without any filler. It is appropriately sized for the tool's simplicity, front-loaded with the key verb 'Check', and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with two well-described parameters and no output schema. The description is sufficient to understand what it does, but it lacks comparison with similar sibling tools and does not clarify what the response will contain. Given the abundance of NFT-related siblings, this minimal context is barely adequate, hence a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: 'tokenId' is described as 'Token ID' and 'contractAddress' as 'NFT contract address'. The description adds no extra semantics beyond the schema, so the baseline 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 function: 'Check who owns a specific NFT token' – a specific verb ('check') plus resource ('ownership' of an NFT token). However, it does not explicitly distinguish itself from sibling tools like nft_get_owned_tokens or vechainstats_get_nft_holders, which could also provide ownership-related information, so it misses the full mark for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any unique use case, prerequisites, or exclusions. Given the large sibling list with similar NFT tools, the lack of usage context makes it hard for an agent to decide if this is the right tool for a given task.
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 the word 'Get' implies a read-only operation, the description does not mention potential pagination, rate limits, or the exact shape of the response. For a simple getter this is minimally acceptable, but it adds little beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function and the data source in under 10 words. Every word contributes value, with no fluff or repetition.
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 (no parameters, no output schema), the description is sufficient for an agent to understand what it returns: a list of all NFT collections. It does not explain what fields are returned, but for a zero-parameter read tool, this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The description appropriately omits parameter details. Baseline is 4 for zero-parameter tools because schema coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all NFT collections') with a specific scope ('on VeChain'), making the purpose obvious. It also mentions the data source (VeChainStats API). However, it does not explicitly distinguish this from the similar sibling 'vechainstats_get_nft_list', so it loses a point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only says it uses the VeChainStats API, but does not state when to prefer this over other NFT-related tools like 'nft_get_collection_info' or 'vechainstats_get_nft_list'. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'check if exists' without specifying the return format (e.g., boolean, status code), error behavior for invalid/missing tokens, or whether this involves a network call. The absence of any such details leaves significant ambiguity about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, six-word sentence that is extremely concise and front-loaded. Every word earns its place, and it avoids any extraneous detail, 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?
For a simple existence check with one required parameter and no output schema, the description is adequate but not fully complete. It doesn't state what the return value represents (e.g., does it return 'true'/'false' or a 200/404 status?) or any error conditions. Given the absence of an output schema, the description should have clarified the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter (tokenId) with a clear description. The tool description adds no additional semantic value beyond what the schema provides, so the baseline score of 3 applies. There is no need for further compensation given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('if a StarGate NFT token exists'), clearly stating the tool's exact purpose. It distinguishes itself from sibling tools like nft_check_ownership or nft_get_metadata by focusing purely on existence rather than ownership, metadata, or other attributes.
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 use cases, prerequisites, or why one would choose this over nft_check_ownership or vechainstats_get_nft_info. Users are left to infer the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention irreversibility, signing requirements, transaction fees, or side effects, which are critical for a fund-transferring mutation. The description is functionally a tautology of the tool's purpose, providing no additional 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 a single, concise sentence that front-loads the key action and resource, with no wasted words or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple, fully documented parameter schema, but the description lacks behavioral context (e.g., on-chain execution, irreversibility, output format). Without annotations or output schema, the description is minimally viable but leaves important operational details unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions ('to', 'amount' in VET, optional 'memo'). The description adds no extra parameter meaning, but the schema already documents all fields, so the baseline score of 3 applies.
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 uses a specific verb ('Transfer') and resource ('VET'), explicitly noting 'native VeChain tokens' to distinguish from token transfers like VIP180. This clarity differentiates it from siblings such as transfer_token and nft_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when-to-use guidance, exclusions, or alternatives. It only states the action, leaving the agent to infer the appropriate context. There is no mention of prerequisites like sufficient balance or that this tool is for native VET only, unlike transfer_token.
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 implies a read-only operation via the word 'check', but does not disclose return format, error behavior, or any side effects. The added context about B3TR funds and rewards pool is helpful but does not explain what the agent should expect from the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and a simple read operation. The description tells the agent what it does and which parameter to supply, but it does not explain what the response will contain (e.g., the fund amount). Given the simplicity, it is adequate for basic selection and invocation, but it leaves the return value to the agent's inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (appId is described as 'VeBetter App ID'). The tool description adds minimal extra meaning by clarifying that the appId refers to the app for which funds are checked, but this does not significantly go beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check'), a clear resource ('available B3TR funds in the rewards pool'), and scope ('for an app'). This clearly distinguishes it from sibling tools like vebetter_claim_rewards or vechainstats_get_balance, making it evident what the tool does.
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 explicit guidance on when to use this tool or how it compares to alternatives. It does not mention prerequisites (e.g., the app must exist) or exclusions, only implying usage through its purpose statement.
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, the description carries the full burden of behavioral transparency. It only describes the input format and does not disclose what the block data contains, whether it is a full vs. summary representation, or any error/edge-case behavior. Minimal context is added beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the key information (action, resource, identifier format). No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so a brief description may suffice. However, without annotations or return-value details, the description is somewhat thin but adequate for a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter 'blockref' has a description matching the tool description. While the parameter semantics are clear from the schema, the description adds no new meaning beyond restating the required format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get block'), the specific resource ('block'), and the distinct lookup method ('by block reference'), which is an 8-byte hex string. This distinguishes it from sibling tools like get_block_by_timestamp and get_block_info, which use different identifiers.
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. It does not mention exclusions, prerequisites, or scenarios where another block-lookup tool would be more 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?
There are no annotations, so the description carries full responsibility for disclosing behavior. It only says 'Get', which implies a read-only operation, but does not describe what is returned (e.g., raw numbers, decimals), whether addresses or symbols are resolved, or potential failure modes. This is minimal context beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states what the tool does. There is no fluff, and the structure front-loads the core action and resource. It is appropriately sized for the tool's simplicity.
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 low complexity and the schema's complete parameter coverage, the description is almost sufficient. The only gap is the lack of return-format information, but for a simple read-only getter this is not critical. The description provides enough for an agent to select the tool correctly and understand its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters with 100% coverage. The description adds the relation 'token pair' and 'DEX', but this is largely implied by the parameter names and schema. Since the schema does the heavy lifting, 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.
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 function: 'Get liquidity pool reserves for a token pair on a DEX'. It uses a specific verb ('Get') and names the exact resource ('liquidity pool reserves') along with the context ('token pair on a DEX'). This distinguishes it from sibling DEX tools like dex_get_swap_quote or dex_get_trade_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or edge cases. While the input schema defines parameters, it offers no contextual hint about when reserve data is needed (e.g., for slippage calculation) versus other DEX querying tools.
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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It does not state that this is a read-only operation, nor does it mention rate limits, caching, possible errors, or any side effects. The only added context is the VeChainStats data source, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a useful parenthetical source note. It is front-loaded with the key verb and resource, contains no filler, and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool, the description is reasonably complete: it names the return scope (floor price and market data), the required identifier, and the data source. However, it could be stronger with a note on the output shape or usage constraints, especially since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents collectionId with type and description ('NFT collection ID or contract address'). The description adds no new meaning beyond reaffirming that the tool operates on an NFT collection, so it does not improve on the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (get), the resource (floor price and market data for an NFT collection), and distinguishes it from siblings like nft_get_collection_info by focusing on pricing data. The verb 'Get' plus the specific resource makes the purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives such as nft_get_collection_info, nft_get_metadata, or vechainstats_get_nft_info. The only implied usage context comes from the tool name and the phrase 'NFT collection,' but no explicit when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the main action (stake and mint) but omits crucial details like lock-up period, maturity, reversibility, or the need for a VET balance. Sibling tools like get_maturity_end_block suggest such aspects, but the description doesn't address them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and outcome. Every word earns its place, and it avoids unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a staking/minting transaction, the description is too sparse. It doesn't explain what happens to staked assets, how to unstake, or any lock/maturity conditions. With no annotations or output schema, the description alone is inadequate for a complex action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for both parameters (levelId and autoDelegate) with descriptions. The tool description adds no additional semantics, such as how level names map to levelId range or the effect of autoDelegate, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stakes VET to mint a StarGate NFT, listing specific NFT levels. This distinguishes it from sibling tools like unstake_stargate_nft and get_staking_levels.
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 a user wants to stake VET to mint an NFT, but provides no explicit when-to-use guidance or exclusions. It doesn't mention alternatives or prerequisites, relying on the uniqueness of the action.
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, the description carries the full burden of behavioral disclosure. It does not mention that claiming likely involves an on-chain transaction, potential gas costs, or irreversibility. The minimal description leaves significant behavioral unknowns for a state-changing 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 a single, concise sentence that immediately communicates the action and object. There is no redundant or filler content, and it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs a claim action, which is likely a transaction with side effects, yet the description lacks information about prerequisites (e.g., having available funds), return values (e.g., transaction hash), or any required authentication. With no annotations and no output schema, the description should provide more context but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('appId' and 'amount'), so the schema already defines their meaning. The description adds no extra parameter context, which is acceptable given the high schema coverage, but it doesn't provide format or source details beyond the basic schema descriptions.
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 ('Claim'), the resource ('accumulated B3TR rewards'), and the context ('from a VeBetter app'). This distinguishes it from the sibling tool 'claim_vtho_rewards' by token type and source (VeBetter app).
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 there are accumulated B3TR rewards from a VeBetter app, but it does not explicitly state when to use this tool versus alternatives like 'claim_vtho_rewards' or 'vebetter_check_available_funds'. No exclusions or related-tool guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The 'Get' verb implies a read-only operation, and the parenthetical list adds some clarity about the returned data. However, it does not disclose any potential limitations, such as real-time vs. historical data, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded with the action and resource, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple zero-parameter getter, but it lacks disambiguation from the similarly named sibling tool vechainstats_get_network_stats and does not describe the response structure, which would be helpful given no output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so the description naturally does not need to explain parameter semantics. Per the rubric, a zero-parameter tool earns a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'network-wide totals' and specifies the categories (accounts, transactions, contracts, blocks). The verb 'Get' and resource are specific, but no explicit differentiation from the sibling tool vechainstats_get_network_stats is provided.
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 or when not to use it. There is no mention of related tools or scenarios where a different tool would be preferred.
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 simply states a read operation ('Get') without disclosing behavioral details such as return format, pagination, handling of missing chainId, or any limitations/errors. 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 a single concise sentence that efficiently communicates the core purpose. The appended '(section 3.2)' is somewhat cryptic and adds no functional value but does not significantly harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-getter with one optional parameter, the description covers the basic purpose. However, with no output schema and no annotations, it does not specify the return value or behavior, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the chainId parameter with a description. The tool description adds no additional meaning beyond the schema's explanation, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('tokens supported by XFlows') with a scope ('for a specific chain'). This distinguishes it from sibling tools like xflows_get_supported_chains, which retrieves chains, not tokens.
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 hints at usage context by mentioning 'for a specific chain', implying a chainId filter, but provides no explicit guidance on when to use this vs alternatives, nor any exclusions or prerequisites. This falls short of clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'status' but doesn't specify status values, return format, or confirm the read-only nature of the call. This is 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 a single, clear sentence, front-loaded with the primary purpose, and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately states the core function. However, it doesn't elaborate on the return structure or what 'status' means, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the optional dexName parameter with 100% coverage, so the description need not repeat it. The description adds no additional parameter context, fitting the baseline of 3.
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 identifies the tool as retrieving a list of available DEXes on VeChain, including their status. This specific verb and resource distinguish it from sibling DEX tools like dex_get_swap_quote and dex_execute_swap.
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 the tool is for discovering available DEXes, but it provides no explicit guidance on when to use it versus other DEX-related tools. No alternatives or exclusions 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 must carry full behavioral transparency. It only states 'calculates expected output amount', which implies a read-only operation but does not explicitly confirm that the tool does not execute the swap, nor does it disclose any error conditions, fee handling, or whether the quote is simulated without on-chain 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 a single sentence that is front-loaded with the action and resource, and the parenthetical adds the key output meaning. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters and no output schema or annotations. The description explains the purpose and the primary return (expected output amount), but it does not detail the output structure, potential additional quote fields (e.g., price impact, route), or prerequisites. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter definitions (e.g., 'Input token symbol or address', 'Amount to swap (decimal string)'). The tool description adds no additional parameter semantics beyond the schema, so baseline 3 applies.
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 uses a specific verb 'Get' and identifies the resource as 'a quote for token swap on a VeChain DEX', with a clarifying parenthetical 'calculates expected output amount'. It clearly distinguishes from sibling tools like dex_execute_swap (executes swaps) and dex_calculate_slippage (calculates slippage).
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 the tool is used to obtain a quote before executing a swap, but it does not explicitly state when to use it versus alternatives (e.g., dex_execute_swap) or mention any exclusions. There is no 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'Get' implies a read-only operation and the description mentions the return content (requirements and rewards), but it does not disclose additional behavioral traits such as response structure, potential sorting, or any side effects. It is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the core function and key output details. There is no unnecessary repetition or filler, making it concise 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?
The tool is simple (one optional parameter, no output schema, no annotations), but the description does not fully cover context like the meaning of categories, default behavior, or how the response is structured. It provides the essentials but leaves room for ambiguity regarding filters and output, so it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single parameter 'category' fully described in the schema. The description does not add any meaning beyond the schema, such as explaining the enum values or default behavior. Since the schema already documents the parameter, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('StarGate staking levels') with additional detail about the content ('requirements and rewards'). This clearly distinguishes it from sibling tools like stake_vet or get_user_stakes, which concern individual staking actions or user-specific 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 such as get_stake_info or get_token_level. It does not state any prerequisites, use cases, or exclusions, so an agent may be unsure which tool to invoke for a given query about staking levels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state the return format, error conditions, whether a wallet must be connected, or any side effects. It merely restates what the tool name implies.
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 one short sentence with no wasted words, front-loaded with the verb and object. It is appropriately sized for the tool's simplicity.
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 getter, the description is minimally adequate, but it lacks explicit mention of the return value and any prerequisites like requiring a connected wallet. With no annotations or output schema, a bit more context would improve completeness, though the tool's simplicity avoids severe 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 zero parameters, so there is nothing to explain. Baseline 4 applies as there are no parameter semantics to add. The description adds no parameter information, but none is needed.
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 uses a specific verb 'Get' with a clear resource 'connected wallet address', which precisely states the tool's function. It distinguishes itself from sibling tools like get_balance or transfer_vet by focusing on the wallet address retrieval.
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 any prerequisites, such as needing a connected wallet, or situations where this tool would be preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. 'Burn (destroy)' communicates that the action is destructive and irreversible, but it does not mention ownership/approval requirements, on-chain transaction implications, gas fees, or confirmation behavior, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence: 'Burn (destroy) an NFT token'. Every word is meaningful and there is no 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?
This is a simple 2-parameter mutation with no output schema and full schema coverage for parameters, so the description only needs to convey the core action and any critical prerequisites. It conveys the core action ('burn/destroy') but omits ownership prerequisites and what happens after execution, making it minimally complete rather than thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for both required parameters (tokenId and contractAddress). The description adds no parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Burn' with parenthetical 'destroy' and clearly identifies the resource as 'an NFT token'. It distinguishes this tool from siblings like nft_transfer, nft_mint, and nft_approve by describing the destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as token ownership or approval. The only implied usage comes from the tool's name and the verb 'Burn'.
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 discloses only the basic read operation ('Get metadata') but does not mention return format, potential errors, token ownership requirements, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose with no unnecessary words. It is front-loaded and highly readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with fully described parameters and no output schema. The description adequately states the basic action, but lacks any additional context such as chain-specific details or behavior when the token doesn't exist, making it merely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both tokenId and contractAddress are described). The description adds no extra parameter semantics beyond the schema, which meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'metadata for a specific NFT token'. It is specific enough to distinguish from sibling tools like nft_get_collection_info or nft_get_floor_price, as it targets a single token's metadata.
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 you need metadata for a single NFT token. However, it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or contextual hints beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read-only operation, which is transparent, but it does not disclose potential pagination, response format, or error behavior. It adds some context (ownership filtering) but lacks richer behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description is adequate but not complete. It does not mention the return type or any limitations, and there is no output schema to fill that gap. Given the low complexity, a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'address' and 'collectionAddress'. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
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 'Get all NFTs owned by a specific address' uses a specific verb and resource, and clearly specifies the scope (owned by an address). This distinguishes it from sibling tools like nft_get_metadata or nft_get_transfer_history, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. While the purpose implies its use, there is no explicit direction for selecting it over similar tools like vechainstats_get_nft_list or get_ids_owned_by.
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 does not state that this is a read-only operation, whether an address must exist, or any side effects. The mention of data types gives some insight but not enough to fully understand tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and front-loaded with the action and resource. No unnecessary words or redundancy, making it 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?
The tool is simple but lacks an output schema and usage guidance. The description gives useful examples of the returned data, but it does not clarify what the 'expanded' flag changes, nor does it distinguish this tool from similar account stats tools. With no annotations, some gaps remain.
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 covers all parameters with descriptions, providing a baseline of 3. The description adds context about VTHO details (generation rate, accumulated), but it does not explain the 'expanded' parameter beyond the schema's minimal 'Include expanded details', so value added is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed VTHO information for an account, with specific examples (generation rate, accumulated). This distinguishes it from sibling tools like get_account_info, which would cover broader account details.
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 VTHO info is needed but does not explicitly discuss alternatives or when not to use. It lacks a clear 'use this when' or exclusion statement that would help an agent decide between similar account-related tools.
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 present, so the description alone must disclose behavior. It only states the tool 'gets' statistics and trends, but provides no information about data source, update frequency, time ranges, or return format. This is a significant gap 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 a single, focused sentence that conveys its purpose without any clutter or repetition. It is appropriately concise for a simple getter tool.
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?
This is a low-complexity tool with no parameters and no annotations, but there is no output schema. The description tells what it returns at a high level but omits specifics such as what 'trends' includes, time ranges, or response structure. It is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the rubric, zero parameters receives a baseline of 4. The description does not need to explain parameters, and no additional parameter semantics are required.
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 function with a specific verb ('Get') and resource ('gas price statistics and trends'). It is distinct from all sibling tools, none of which mention gas stats, so there is no ambiguity about what this tool does.
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. Given the absence of any comparison to sibling tools or discussion of scenarios, the description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the operation but does not reveal the return format, whether both VET and VTHO are returned as separate fields, error handling for invalid dates or blocks, or the relationship between date and blocknum when both are provided. This lack of context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without any redundant or extraneous information. It is efficiently front-loaded 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?
The tool is relatively simple, but since there is no output schema and no annotations, the description should provide more context about the response structure and edge cases. It covers the core operation but lacks details on what the returned balance looks like, units, and behavior if no date or blocknum is specified. This makes it minimally adequate but not fully 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?
Schema descriptions cover all three parameters, providing a baseline of 3. The description adds meaning by indicating that 'date' and 'blocknum' are alternative ways to specify the historical point ('at a specific date or block'), and that the balance pertains to both VET and VTHO, which is not evident from the parameters alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'historical VET/VTHO balance' with the scope 'at a specific date or block'. This distinguishes the tool from current balance tools like vechainstats_get_account_info or token-specific tools like vechainstats_get_vip180_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for historical balances as opposed to current balances, nor does it reference any sibling tools or exclusions. The agent is left to infer usage solely from the tool name.
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, the description carries full responsibility for behavioral disclosure. It only lists return content (supply, holders, metadata) and does not disclose effects of the 'expanded' parameter, error behavior, or any operational constraints. This is a read operation but that is implicit via 'Get', not elaborated.
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?
A single, front-loaded sentence that states the action and key information categories. There is no redundancy or unnecessary detail, 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?
The description gives a sense of the return content ('supply, holders, metadata') but is incomplete for a tool with no output schema. It omits details about the 'expanded' parameter and does not clarify what 'metadata' entails, leaving ambiguity for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, including descriptions for both 'token' and 'expanded'. The description adds no additional meaning about parameter usage or formatting, so it meets the baseline without improvement.
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 uses a clear verb 'Get' and identifies the specific resource 'detailed token information' with concrete aspects (supply, holders, metadata). This distinguishes it from sibling tools that focus on individual aspects like supply or holders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for comprehensive token information but does not explicitly state when to use it over alternatives like vechainstats_get_token_supply or vechainstats_get_token_holders. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive' and 'metadata' but does not disclose any behavioral traits such as response size, pagination, performance implications, or data freshness. For a list endpoint, at least noting the potential for a large payload or rate limits would add transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains no filler. It earns its place by conveying the core purpose and scope without 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?
For a zero-parameter tool, the description is minimally viable but lacks detail about the return value. 'With metadata' is vague—unclear whether it includes token address, symbol, decimals, total supply, etc. Given no output schema and no annotations, a brief elaboration on the metadata fields or the nature of the response would make it more 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?
The input schema has zero parameters, and the description accurately reflects a no-argument list operation. Per the baseline, with 0 params the description need not elaborate on parameter semantics. The term 'comprehensive list' also implicitly signals that no filters are applied.
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 uses a specific verb ('Get') and clearly identifies the resource ('comprehensive list of all tokens on VeChain with metadata'). It distinguishes from sibling tools like vechainstats_get_token_info (single token) and vechainstats_get_all_token_prices (prices only) by emphasizing the comprehensive list scope.
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 vs alternatives. With many token-related sibling tools (e.g., get_token_info, get_token_price, token_exists), the description does not clarify that this is for the full list, not for queries about a specific token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It only states the basic read action without mentioning response format, pagination, error cases, or anything about the expanded parameter's behavior. For a read tool, the absence of side effects is implied but not stated, and no other behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It contains no filler or redundant information, and the key verb and object are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and no output schema, so the description's brevity is somewhat acceptable. However, it lacks usage guidance and for a tool without an output schema, it does not fully describe return values beyond listing 'total, circulating' as examples. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters ('token' and 'expanded'), so schema coverage is 100%. The description does not add any new parameter-specific meaning beyond what the schema already provides, earning the baseline score of 3.
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 identifies the tool's action ('Get') and resource ('token supply information'), with specifics like total and circulating supply. This distinguishes it from sibling tools like get_token_info and get_token_price, which focus on other aspects of tokens.
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 its usage for retrieving token supply data but does not explicitly state when to prefer it over alternatives or provide exclusions. There is no mention of when to use expanded details or how it relates to sibling tools, so usage context is only implied.
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 burden of disclosing behavioral traits. It mentions pagination, which is useful, but does not disclose whether transactions are limited to confirmed ones, whether sorting defaults apply, or any rate limits or errors. The read-only nature is implied by 'Get' but not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word contributes meaning: it identifies the action, the resource, the filter, and a key feature (pagination).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality but lacks detail about the return format or fields, and there is no output schema. For a simple read tool with pagination, it is minimally viable, but it does not explain what the response contains or any edge cases like empty results or invalid addresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a 100% description coverage for all three parameters (address, page, sort). The description adds only a general mention of 'pagination,' which aligns with the page parameter but does not add extra semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a resource ('outgoing transactions'), and a scope ('for an address'), with pagination mentioned explicitly. This distinguishes it from siblings like vechainstats_get_transactions_in, which would cover incoming 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?
There is no guidance on when to use this tool versus alternatives such as vechainstats_get_transactions_in. The description does not mention exclusions, prerequisites, or complementary tools, leaving the agent to infer usage solely from the tool name.
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. The verb 'Calculate' implies a pure off-chain computation without side effects, but it does not disclose the return format, rounding behavior, or that it is deterministic. The schema example for slippagePercent adds some context, but the description itself is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, fully front-loaded with the core purpose. Every word earns its place, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter calculation tool with complete schema descriptions and no output schema, the description covers the essential purpose. However, it lacks explicit details about the calculation formula, return value type, and rounding behavior, which are relevant for a financial calculation. Still, given the tool's simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters ('Expected output amount' and 'Slippage tolerance percentage (e.g., 0.5 for 0.5%)'). The description text does not add any additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Calculate' and a specific resource 'minimum output amount based on slippage tolerance'. This clearly distinguishes it from siblings like dex_get_swap_quote (which returns quotes) and dex_execute_swap (which executes trades).
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 information about when to use this tool versus alternatives, such as after obtaining a quote or to compute the minimum acceptable output before executing a swap. No exclusions or alternative references are given.
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?
Annotations are absent, so the description carries the burden. It indicates a read operation via 'Get' and specifies the returned data (supply and cap), but does not explicitly state read-only safety, auth requirements, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, clearly structured, no redundancy. It immediately names the action and data returned.
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 one-parameter getter, the description is adequate: it names the level, the data returned, and the schema defines the parameter. However, without output schema or annotations, the agent lacks details on value units/format, but this is not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described levelId parameter (type, min, max). The description adds no additional meaning beyond naming 'specific StarGate level', so it stays at the schema-driven baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves circulating supply and cap for a specific StarGate level, using a specific verb ('Get') and resource. It distinguishes from sibling tools like get_token_supply by specifying 'StarGate' and 'level'.
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. The description implies usage for a given levelId, but does not mention similar tools or exclusions, leaving the agent to infer.
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 must disclose behavioral traits on its own. It implies a read-only operation (getter) and specifies the NFT domain, but does not state potential outcomes such as errors for invalid token IDs, whether the result is a raw integer, or if any off-chain state is involved. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. There is zero wasted wording, making it easy to parse quickly.
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 single-parameter getter, the description covers the essential purpose and expected output ('block number'). It lacks an output schema but the return type is intrinsically clear. However, it could benefit from mentioning related checks like is_under_maturity_period to provide fuller context within the toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the sole parameter (tokenId) with a clear description: 'Token ID to get maturity end block for'. Since schema coverage is 100%, the tool description does not need to repeat parameter details. It adds no extra semantic value beyond the schema, so the baseline score of 3 applies.
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 function: 'Get the block number when the maturity period ends for a StarGate NFT'. It specifies a precise verb (get), resource (block number), and scope (StarGate NFT), effectively distinguishing it from sibling tools like is_under_maturity_period or get_token_level.
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 explicit guidance on when to use this tool versus alternatives. It does not mention related tools like is_under_maturity_period or suggest scenarios where this block number is needed (e.g., to compare against the current block). Without any usage context, the agent must infer applicability solely from the name.
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 says 'Get' but does not explicitly state it is read-only or disclose any limitations. The term 'stakes' in the tool name conflicts with 'all StarGate NFTs owned' in the description, creating ambiguity about whether it returns only staked NFTs or all owned NFTs. This lack of clarity undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the action and resource. It contains no wasted words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what 'detailed information' includes and clarify the relationship between 'stakes' and 'owned'. The ambiguity about scope (staked vs. all owned) makes the description incomplete for an agent to predict the tool's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'address' with a description. The tool description adds valuable context that the stakes refer to StarGate NFTs, clarifying what the address parameter is for beyond the generic schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('all StarGate NFTs owned by an address'), with an added qualifier ('with detailed information'). It distinguishes from generic NFT listing tools by specifically naming StarGate NFTs.
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?
Usage is implied: this tool is for fetching StarGate NFTs for a given address. However, it does not explicitly mention when to prefer this over alternatives like get_ids_owned_by or nft_get_owned_tokens, nor does it provide any 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 present, so the description carries full behavioral burden. It only states the action without disclosing that this is a blockchain transaction, may require signing/authentication, may fail due to insufficient balance, or may be irreversible. The return value and side effects are also undisclosed.
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?
Single sentence, 9 words, front-loaded with action and resource, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transfer tool with four required parameters, no output schema, and no annotations, the description is under-specified. It omits crucial context about the transaction lifecycle, potential failure modes, prerequisites, and return values.
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 descriptions cover all four parameters, so baseline is 3. The tool description reinforces the tokenSymbol examples and confirms the 'to' parameter is an address, but adds no new syntax, dependencies, or format details beyond 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?
Clearly states the action (Transfer), the resource (VIP-180 tokens), and the destination (another address). The inclusion of example tokens (VTHO, B3TR) distinguishes it from native VET transfer and NFT transfer siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the target asset class (VIP-180 tokens), which implies the primary use case and differentiates from transfer_vet (native VET). However, it does not explicitly state when not to use this tool or name alternatives, so it falls short of a full usage guideline.
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 disclosing behavioral traits. The description only restates the tool's function ('Get carbon emissions') without mentioning whether it is read-only, what data is returned, any authentication/rate limits, or how the multiple optional parameters interact. This is a minimal disclosure with no added context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the action. It provides both function and context without any redundant text. The phrase 'perfect for VeBetter sustainability tracking!' is short and adds usage context, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must compensate by explaining the tool's behavior and parameter selection. It fails to clarify how the optional parameters relate (e.g., address vs txid vs blocknum) or what the response contains. For a tool with four optional parameters, this is insufficient guidance for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters (txid, address, blocknum, timeframe). The tool description adds no additional parameter meaning or usage guidance, so it does not elevate beyond the schema baseline. The baseline of 3 applies because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Get carbon emissions (CO2e) for an address'. This distinguishes it from sibling tools like vechainstats_get_transaction_emissions and vechainstats_get_network_emissions by specifying the address scope. The added use-case of 'VeBetter sustainability tracking' provides clear context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: for address-based emissions, as opposed to transaction or network emissions. It also mentions a specific use case (VeBetter sustainability tracking). However, it does not explicitly name alternatives or provide exclusion criteria, but the address scope is clear from the first sentence.
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 burden. It implies a read operation but does not disclose pagination behavior, threshold filtering effects, or output format. It is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It immediately states the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description is adequate but not complete. It does not explain pagination or threshold behavior, but given the schema provides some parameter details, it is minimally sufficient.
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 67% (id and threshold have descriptions, page does not). The tool description adds no parameter meaning beyond stating the collection context, leaving the 'page' parameter undocumented and not clarifying threshold semantics.
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 uses a specific verb ('Get list') and resource ('NFT holders') with a clear scope ('for a collection'), which clearly distinguishes it from sibling tools like vechainstats_get_nft_info or vechainstats_get_nft_transfers.
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 (when you need NFT holders for a collection), but does not explicitly provide when-to-use vs alternatives or exclusions. Sibling tools exist for NFT transfers and info, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only check ('Check if') but does not disclose return format, error behavior for nonexistent tokens, or any edge cases. It is minimally transparent but lacks specific behavioral details that would help an agent anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose without unnecessary words. It earns its place and is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema, so the description should clarify what the tool returns. 'Check if' implies a boolean, but it is not stated explicitly. The description covers the core purpose but omits return value details and edge-case behavior, leaving minor gaps for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 'Token ID to check transfer eligibility' already providing adequate meaning for the single parameter. The description's mention of 'StarGate NFT' adds slight context about the token type, but it does not go beyond what the schema already conveys, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and names the resource ('StarGate NFT') along with the condition ('maturity period has ended'), making it clear what the tool does. It distinguishes itself from sibling tools like 'get_maturity_end_block' and 'is_under_maturity_period' by focusing on transfer eligibility rather than maturity timestamps or period status.
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 one needs to know if an NFT can be transferred, but it does not explicitly state when to use this tool versus alternatives like 'is_under_maturity_period' or 'get_maturity_end_block'. No exclusions or preferred contexts are given, leaving the agent to infer usage from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits directly. It does disclose an important authentication requirement (minter role). However, it does not mention that this is an irreversible on-chain transaction, likely incurring gas costs, nor does it describe the expected response or failure modes. It adds some context but lacks a fuller disclosure for a mutation 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 a single, front-loaded sentence that efficiently states the action and a key prerequisite in parentheses. It contains no fluff and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema provides complete parameter documentation, and the description gives a clear purpose and a minter-role requirement. However, as a blockchain write operation with no output schema, the description omits important context such as the transaction nature, gas requirements, and return value expectations. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions already fully document each parameter. The tool description adds no additional parameter-specific meaning, keeping it at the 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 uses a specific verb 'Mint' with a clear resource 'new NFT token', making the action unambiguous. The parenthetical 'requires minter role on contract' adds a relevant constraint. This clearly distinguishes it from sibling tools like nft_burn, nft_transfer, and nft_approve.
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 implicitly defines when to use the tool (to create a new NFT) and provides a clear prerequisite: the minter role. However, it does not explicitly contrast with alternatives or state when not to use it. 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 must fully disclose behavior. It only says 'Get list' and does not mention return format, pagination, data scope, freshness, or any access requirements. The read-only nature is implied but not explicit.
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?
A single sentence with no wasted words directly states the action and object. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is minimally adequate. However, there is no output schema and the description does not specify what fields or structure the returned list contains, nor any scope (all nodes, current state, etc.), leaving the agent with incomplete 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 zero parameters, and the schema is empty with 100% coverage. With no parameters to document, the baseline of 4 applies; the description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and the resource ('X-Nodes'), adding disambiguation with 'economic nodes'. This distinguishes it from sibling list tools like authority nodes or node token stats.
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 usage is implied by the purpose (if you need X-nodes, use this), but there is no explicit when/when-not guidance or alternatives named. Among many similar vechainstats_get_* tools, no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavioral traits, but it discloses none. It lacks any mention of response format, pagination, rate limits, or data freshness. The description only restates the basic function.
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?
A single, front-loaded sentence with no wasted words. It conveys exactly what the tool does in one line.
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 low complexity (no parameters, no output schema), the description is adequate for an agent to understand its purpose. It could mention the return format, but that is not essential for a simple list getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is vacuously fully covered. The description does not need to add parameter details, and the baseline for 0-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and the resource ('authority nodes (validators) on VeChain'). It is specific enough to distinguish from sibling tools such as vechainstats_get_current_block or vechainstats_get_node_token_stats.
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 agent needs a list of authority nodes—but it does not provide explicit when-to-use/when-not-to-use guidance or mention any alternatives. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly implies a read-only operation, but it does not describe the exact return value format (e.g., integer vs string), potential delays, or any edge cases, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and immediately states the purpose, achieving maximum conciseness.
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 tool with no parameters and no output schema, the description sufficiently explains what it does. However, it could be more explicit about the return value being a numeric block height, and there is no mention of the data source or any casual constraints, so it stops short of full 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 input schema has zero properties, so there are no parameters to explain. Baseline 4 applies because no parameter documentation is needed, and the description adds no parameter-related value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'the current block height of VeChain'. It unambiguously states what the tool returns and distinguishes itself from siblings like get_block_info, which fetches block details by number, and get_block_by_timestamp, which locates blocks by time.
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?
There is no guidance on when to use this tool versus alternative block-related tools. The description gives no context about choosing it for current height queries, nor does it mention exclusions or alternatives.
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 burden of disclosure. It mentions pagination, which is behavioral, but does not detail return format, default sort behavior, or any potential limitations. For a read-only retrieval tool, this is minimally adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the key verb and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-fetching tool with only 3 parameters and no output schema, the description is fairly complete. It conveys the core purpose and pagination feature. It could be more explicit about the distinction from outgoing transactions, but this is a minor gap given the simple nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond 'address' and 'pagination' that isn't already in the schema; it does not enhance understanding of page, sort, or address semantics.
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 states the exact action ('Get incoming transactions'), the target resource ('for an address'), and a key feature ('with pagination'). It clearly distinguishes from the sibling vechainstats_get_transactions_out by specifying 'incoming'.
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 (e.g., incoming transactions for an address), but it does not explicitly state when to prefer this over alternatives, such as vechainstats_get_transactions_out, nor does it mention exclusions or alternative tools. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get all chains' implies a read-only list operation, but it does not disclose return format, potential empty results, or any side effects. This is adequate but minimal for a zero-parameter getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. However, the parenthetical '(section 3.1)' adds little value and could confuse users without the referenced document, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description conveys the core function, but because there is no output schema, it should ideally hint at the return shape (e.g., list of chain IDs/names). This omission leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. Per the rubric, the baseline is 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all chains supported by XFlows'. The verb 'Get' and resource 'chains supported by XFlows' are specific and distinguishes it from sibling tools like xflows_get_supported_tokens.
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 supported chains, but provides no explicit when-to-use guidance or alternatives. It does not mention that xflows_get_supported_tokens should be used for token queries, leaving differentiation to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the key behavioral trait: the tool returns transaction data for wallet signing, not actually executing the bridge. However, it omits details about fees, prerequisites, or side effects, which are relevant for a creation 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 a single, front-loaded sentence that states the action and the return value. Every word contributes value; there is no 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?
The absence of an output schema places importance on describing the return value, which it does at a high level ('transaction data ready for wallet signing'). However, for a complex tool with 8 parameters and no workflow context, it lacks depth about prerequisites or integration with other bridge steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all 8 parameters documented, so the baseline is 3. The description adds no extra parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a cross-chain bridge transaction using WanBridge API and returns transaction data for wallet signing. This is a specific verb+resource and distinguishes it from sibling bridge tools like bridge_get_quota_and_fee or bridge_check_status.
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 gives a clear context (WanBridge API) but provides no explicit when-to-use guidance or alternatives. It does not differentiate from similar tools like xflows_build_transaction, leaving decision-making to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and explicitly discloses the key destructive effect: 'burn it'. It also specifies the reward (retrieve staked VET). However, it omits other behavioral details such as ownership requirements, maturity locks, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 12-word sentence, front-loaded with the action, and contains no filler or repetition.
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 one-parameter state-changing tool, the description states the core effect and purpose clearly. However, it lacks context about when to invoke it (e.g., after maturity) and what conditions must hold, making it minimally viable rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents tokenId as 'Token ID to unstake', and the description adds no additional parameter semantics beyond restating the action. Baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Unstake' with the resource 'StarGate NFT' and clearly states the result 'burn it and retrieve the staked VET'. This distinguishes it from sibling tools like nft_burn (generic burn) and get_user_stakes (read-only).
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 the usage—for exiting a StarGate NFT stake—but lacks explicit guidance on when to use it versus alternatives like claim_vtho_rewards or can_transfer_stargate_nft. It does not state prerequisites or when-not-to-use.
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 only says 'Get prices' but does not disclose potential response size, pagination, rate limits, price freshness, or any side effects (though likely none). The lack of any detail about the returned data format or operational characteristics is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is immediately informative. It avoids filler words and clearly communicates the tool's purpose and differentiating feature ('in one call').
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?
This is a simple no-parameter tool, but without an output schema or annotations, the description should at least hint at what 'prices' means (e.g., currency, format, or whether it includes all known tokens). The description is minimally adequate but leaves out details that could affect an agent's expectations, such as potential large payload or price time reference.
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 zero parameters, and the schema description coverage is 100% (vacuously). The description does not need to add parameter semantics, and the baseline for a zero-parameter tool is 4. The description adds no extra parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('all VeChain tokens'), and the scope ('in one call'), which distinguishes it from the sibling tool vechainstats_get_token_price that presumably handles a single token. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'all VeChain tokens in one call' strongly implies this is the batching alternative to the singular get_token_price, giving clear context for when to use it. However, it does not explicitly name the alternative or provide an exclusion condition, so it falls short of a 5.
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 only says 'Get' which implies a read, but it does not explicitly state that it is non-mutating, nor does it describe the return format, potential errors, or rate limits. This is a significant gap for a tool with no structured metadata.
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?
A single, front-loaded sentence conveys the essential purpose with minimal waste. The parenthetical adds useful clarification without bloating the 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?
The tool is simple (0 params) but lacks an output schema, so the description should at least hint at what information is returned. It mentions 'pending transactions' but does not describe the structure (e.g., list vs. count, fields). It is minimally viable but has gaps in what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information, which is acceptable because there is nothing to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current mempool information'), with a parenthetical clarification ('pending transactions') that removes ambiguity. No sibling tool covers mempool, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description imparts clear context: use this tool when needing pending transaction data from the mempool. It does not list exclusions or alternatives, but none are needed given the unique focus of this tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It reveals that the tool is a cross-chain status check and that it can handle hashes from either chain, but it does not disclose the return format, whether the operation is read-only (though implied), or how errors like 'hash not found' are handled. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and followed by a clarifying note about the parameter. Every word earns its place—no fluff, no redundancy.
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 status check with one parameter, the description is mostly complete. It tells the agent what the tool does, what input it accepts, and how it differs from siblings. However, since there is no output schema, a brief note about the expected return values (e.g., status levels, pending confirmation) would improve completeness. The 'section 4.1' reference is cryptic and adds little.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the txHash parameter already described as 'Transaction hash from source or destination chain.' The description adds marginal value by repeating this in natural language and referencing a section, but it does not go beyond the schema semantics. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "Check cross-chain bridge transaction status" with a specific verb and resource. It distinguishes itself from sibling tools by specifying "cross-chain bridge" and noting that it accepts hashes from either side of the bridge, which sets it apart from single-chain status tools like vechainstats_get_transaction_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating that the tool accepts a hash from either the source or destination chain, which tells the agent when to use it (when a bridge transaction hash is available). However, it does not explicitly mention alternatives or exclusions, such as using vechainstats_get_transaction_status for on-chain transactions or xflows_check_status for a different bridge.
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 transparency burden. 'VeChain is carbon-neutral!' adds a meaningful behavioral hint (likely returns zero or a neutrality status), but it does not disclose the output format, units, or data source. This is adequate for a simple read-only getter but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that delivers the core purpose and adds a relevant context note. There is zero wasted content, and the structure is ideal for a simple getter.
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 minimal complexity (no parameters, no output schema), the description is sufficiently complete. It states what the tool does and adds a key behavioral fact about the network's carbon-neutral status. It does not explain the return value, but this is low importance for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are inherently simple. The schema is empty and requires no explanation. Even though the description does not discuss parameters, the baseline for zero-parameter tools is 4, and there is nothing to add.
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 states a specific action ('Get total network carbon emissions') and clearly identifies the resource (network emissions). The scope 'total network' distinguishes it from sibling tools like vechainstats_get_address_emissions and vechainstats_get_transaction_emissions, which focus on different scopes.
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?
Usage is implied: if you need overall network emissions, this is the tool. However, there is no explicit guidance on when to prefer it over the address/transaction emissions siblings or any caveats about the tool's output. It is a simple no-parameter getter, making detailed guidance less critical.
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 does disclose the primary behavior (returns a list of valid categories) and implies read-only via 'Get.' However, it does not mention dynamic behavior, authentication, or any other side effects, which is acceptable for such a simple getter but not particularly rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function without any filler. It is front-loaded and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete. It tells the agent exactly what is returned (a list of valid impact categories) and the context (for VeBetter submissions), which is sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema already reflects this with empty properties. Since there are no parameters to explain, the baseline of 4 applies, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it gets a list of valid impact categories for VeBetter submissions. The verb 'Get' and the resource 'list of valid impact categories' are specific, and the context 'for VeBetter submissions' distinguishes it from sibling tools like vebetter_submit_action or vebetter_claim_rewards.
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 the tool should be used when needing to know valid impact categories for a submission, but it does not explicitly say when to use it or mention alternatives. There are no exclusions or when-not-to-use instructions, so it falls short of clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of signaling side effects. 'Get current' implies a read-only, time-sensitive lookup, which is helpful, but it does not explicitly state safety, return format, or prerequisites. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key action and object, then adds context. Every word earns its place; there is no redundancy or filler.
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, parameterless getter with no output schema, the description provides the essential information: what is returned (smgID) and why it is needed (cross-chain operations). It lacks explicit return type details and references an external section ('section 1.4') that may not be available to the agent, but the tool is low complexity and the description is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter syntax. It still adds meaning by naming the returned value (smgID) and its role in cross-chain operations, matching the baseline for parameterless tools.
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 uses a specific verb ('Get') and names an exact resource ('current Storeman Group ID (smgID)'), immediately clarifying what the tool returns. It also attaches a clear purpose ('for cross-chain operations'), which helps distinguish it from the many other bridge and vault tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for cross-chain operations' gives explicit context for when to use the tool. It does not mention when not to use it or name alternatives like bridge_get_quota_and_fee, so it falls short of a 5, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It states what the tool returns (a hash) and its purpose, which is sufficient for a simple stateless operation. No hidden side effects or additional behavior is expected beyond computing a hash.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is both concise and informative. It contains no filler or redundant details, earning a perfect score for conciseness.
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 (no parameters, no output schema), the description is nearly complete. It explains what the tool does and why it exists. The only minor omission is a specific format for the returned hash, but that is not critical for understanding or using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (zero parameters), so schema coverage is 100%. The description doesn't need to explain parameters, and the baseline for a zero-parameter tool is 4. It correctly avoids adding redundant parameter information.
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 function: 'Get hash of token pairs data to check if it changed (for caching optimization)'. It specifies the resource (token pairs data), the action (get hash), and the purpose (change detection), which distinguishes it from the sibling tool bridge_get_token_pairs that likely returns the full data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the intended use case: 'for caching optimization' and checking if data changed. While it doesn't name alternative tools or provide when-not-to-use guidance, the purpose is clear enough for an agent to infer when to call this tool versus fetching the full token pairs list.
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:

[![vechain-terminal-mcp MCP server](https://glama.ai/mcp/servers/VeChain-AI-Terminal/vechain-terminal-mcp/badges/card.svg)](https://glama.ai/mcp/servers/VeChain-AI-Terminal/vechain-terminal-mcp)

Score Badge

Copy to your README.md:

[![vechain-terminal-mcp MCP server](https://glama.ai/mcp/servers/VeChain-AI-Terminal/vechain-terminal-mcp/badges/score.svg)](https://glama.ai/mcp/servers/VeChain-AI-Terminal/vechain-terminal-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/VeChain-AI-Terminal/vechain-terminal-mcp'

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