VeChain MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as get_account for account info, send_token for transfers, and sign_message for signing. However, there is some overlap between sign_raw_transaction and sign_typed_data_evm, which both involve signing but for different data formats, potentially causing minor confusion. Overall, the descriptions help clarify differences, but the signing tools could be slightly ambiguous.
Naming Consistency4/5
The tool names follow a consistent snake_case pattern with clear verb_noun structures, such as get_balance, send_token, and sign_message. Minor deviations exist, like convert_from_base_units and convert_to_base_units being more descriptive but still adhering to the pattern. The naming is mostly predictable and readable, with only slight variations in verb usage.
Tool Count4/5
With 20 tools, the count is slightly high but reasonable for a blockchain server covering wallet management, token operations, signing, and documentation search. It includes essential functions like account queries, transfers, and approvals, though it borders on being heavy. The tools are well-scoped for the VeChain domain, but some consolidation might improve efficiency.
Completeness5/5
The tool set provides comprehensive coverage for the VeChain blockchain domain, including CRUD-like operations for accounts, tokens, and transactions, as well as wallet creation, signing, and documentation search. There are no obvious gaps; it supports core workflows from querying balances to executing transactions and managing approvals, ensuring agents can handle typical tasks without dead ends.
Average 3.2/5 across 20 of 20 tools scored. Lowest: 2.6/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 is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'decode and sign' but doesn't explain what decoding entails, whether this requires private keys or authentication, if it's a read-only or destructive operation, or what the output looks like. This leaves significant gaps for a signing 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 extremely concise with a single sentence, front-loaded with the core action. There is no wasted text, making it efficient and easy to parse, though this brevity contributes to gaps 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?
Given the complexity of a signing operation, lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't cover behavioral aspects like security implications, output format, or error handling, which are critical for such a tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It implies 'rawTransaction' is the input but doesn't add meaning beyond the schema, such as the expected format (e.g., hex string), encoding, or constraints. This fails to address the coverage gap adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose with the verbs 'decode and sign' and the resource 'a raw transaction', which is clear but somewhat vague. It doesn't specify what type of transaction (e.g., blockchain/EVM) or distinguish it from sibling tools like sign_message or sign_typed_data_evm, which also involve signing 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?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like sign_message and sign_typed_data_evm available, the description lacks context on when this specific signing method is appropriate, such as for raw transaction data versus structured messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action 'sign' but doesn't disclose behavioral traits like required permissions, whether this is a read-only or destructive operation, potential side effects, or error conditions. For a signing tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of EIP-712 signing (4 parameters with nested objects, no output schema, and no annotations), the description is inadequate. It doesn't explain what the tool returns, how errors are handled, or provide any context about the signing process beyond the basic action, leaving significant gaps for an AI agent to understand proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters (domain, types, primaryType, message) are documented in the schema. The description adds no information about what these parameters mean, their expected formats, or how they relate to EIP-712 signing, failing to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'sign' and the resource 'EIP-712 typed data structure (EVM)', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling signing tools like 'sign_message' or 'sign_certificate', which would require more detail about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'sign_message' and 'sign_certificate' available, the description lacks any context about EIP-712-specific use cases, prerequisites, or comparisons to other signing methods.
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 describes the conversion behavior but lacks details on error handling (e.g., invalid inputs), performance traits (e.g., rate limits), or output format (e.g., numeric string). For a tool with no annotation coverage, this is a significant gap in 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, efficient sentence that front-loads the core purpose with a clarifying example. There is no wasted text, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving token conversions with 2 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on parameter usage, error cases, and output format, which are essential for effective tool 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 0%, so the description must compensate. It mentions 'token amount' and 'human-readable units', which loosely relates to the 'amount' parameter, but doesn't explain the 'tokenAddress' parameter or its pattern. With 2 parameters and low coverage, the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert' and the resource 'token amount', specifying the transformation from 'human-readable units to its smallest unit' with an example 'wei'. However, it doesn't explicitly differentiate from its sibling 'convert_from_base_units', which performs the inverse operation, leaving some ambiguity about when to use each.
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. While the description implies usage for converting token amounts, it doesn't mention prerequisites (e.g., token address validation), exclusions, or compare it to sibling tools like 'convert_from_base_units', leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe behavioral traits such as whether it's a read-only operation (implied by 'Get' but not explicit), potential rate limits, authentication needs, error conditions (e.g., invalid addresses), or what the return format looks like (e.g., numeric balance, units). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states the action and scope, making it easy to parse. Every part of the sentence earns its place by specifying the resource and optional token focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose but lacks details on behavioral traits, parameter meanings, return values, or usage context. For a tool that retrieves financial data, more information on output format (e.g., balance in wei or decimals) and error handling would be beneficial to ensure 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 0%, so the schema provides no parameter descriptions. The description mentions 'address' and 'tokenAddress' indirectly by referring to 'wallet' and 'ERC20 token', but it doesn't explain what these parameters mean (e.g., that 'address' is the wallet address, 'tokenAddress' is optional for ERC20 tokens, or the pattern requirements). It adds minimal semantic value beyond what can be inferred from the schema's structure and patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'balance of the wallet', specifying it can be for 'native currency or a specific ERC20 token'. This distinguishes it from siblings like get_account or get_token_info_by_ticker by focusing on balance retrieval rather than general account info or token metadata. However, it doesn't explicitly differentiate from tools like get_address or get_transaction, which might involve similar address parameters but different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid wallet address), exclusions (e.g., not for non-ERC20 tokens), or direct comparisons to siblings like get_account (which might provide broader account details) or get_token_allowance_evm (which checks token permissions). Usage is implied by the purpose but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It mentions the return format ('amount in base units') but doesn't disclose other traits like read-only nature (implied by 'Get'), error conditions, rate limits, or authentication needs. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes key output detail. There is no wasted text, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the basic purpose and output unit but misses parameter explanations, behavioral context, and usage guidelines. For a 3-parameter tool in a blockchain context, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal parameter semantics. It implies parameters for token, owner, and spender through context but doesn't explain their roles (e.g., 'owner' is the token holder, 'spender' is the authorized address). The description mentions base units but not how parameters relate to this output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the allowance') and resource ('of an ERC20 token for a spender'), specifying it returns amount in base units. It distinguishes from siblings like 'approve_token_evm' or 'revoke_token_approval_evm' by focusing on querying rather than modifying allowances, though it doesn't 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 on when to use this tool versus alternatives. For example, it doesn't mention when to choose this over 'get_token_info_by_ticker' for token data or 'get_balance' for balances, nor does it specify prerequisites like needing token addresses. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('sign') but doesn't explain what signing entails (e.g., cryptographic operation, output format, permissions required, or side effects). This is inadequate for a tool that likely involves sensitive wallet operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly, though this brevity contributes to gaps 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?
Given the complexity of a signing operation (likely involving cryptography and wallet access), no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral traits, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'message' but provides no details on format, encoding, or constraints (e.g., plain text, hex, length limits). This adds minimal value beyond the schema's parameter name, failing to address the coverage 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 clearly states the action ('sign') and resource ('message with the wallet'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'sign_certificate', 'sign_raw_transaction', or 'sign_typed_data_evm', which also involve signing operations, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With multiple signing-related siblings (sign_certificate, sign_raw_transaction, sign_typed_data_evm), the description offers no context on use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose critical behavioral traits like required permissions (e.g., token owner), whether this is a blockchain transaction (implying gas fees and confirmation time), irreversible nature, or rate limits. 'Approve' suggests a write operation, but details are 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?
Single sentence, front-loaded with the core action, zero waste. Every word earns its place by clarifying the tool's purpose and parameter context efficiently.
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 complexity (blockchain token approval with 3 parameters), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavioral aspects (e.g., transaction lifecycle, errors), return values, or usage context, making it inadequate 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 0%, so the description must compensate. It adds meaning by specifying 'amount' is in base units (e.g., wei, not decimals) and that 'tokenAddress' and 'spender' relate to ERC20 tokens, but doesn't explain parameter formats (e.g., hex addresses) or constraints beyond what the schema's patterns imply. Baseline 3 as it partially compensates for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Approve') and resource ('an amount of an ERC20 token'), specifying it's for a spender. It distinguishes from siblings like 'revoke_token_approval_evm' (revoke vs approve) and 'get_token_allowance_evm' (get vs approve), but doesn't explicitly differentiate from 'send_token' (which transfers tokens rather than approves spending).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'revoke_token_approval_evm' or 'send_token', nor prerequisites such as token ownership or network conditions. The description implies usage for token approval but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the conversion action but lacks details on permissions, rate limits, error handling, or output format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving token conversion with 2 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on output format, error cases, dependencies, or how it interacts with other tools, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'amount' and 'tokenAddress' parameters by mentioning 'token amount' and 'smallest unit', but doesn't explicitly define them or their formats. The description adds some meaning but doesn't fully document the parameters, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert' and the resource 'token amount', specifying the transformation from 'smallest unit (e.g., wei)' to 'human-readable units'. It distinguishes from sibling 'convert_to_base_units' by indicating the opposite direction, though it could be more explicit about the sibling relationship.
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 is provided. The description implies usage for converting token amounts from base units, but it doesn't mention prerequisites, when not to use it, or compare it to other tools like 'convert_to_base_units' or 'get_token_info_by_ticker' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('Get') but doesn't disclose behavioral traits like whether this is read-only, requires authentication, returns a specific format, or has side effects. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (simple retrieval) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'address' means (e.g., cryptographic, formatted), the return value, or error conditions, leaving gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get the address of the wallet') with a clear verb and resource, but it's vague about which wallet's address is retrieved. It doesn't distinguish from siblings like 'get_account' or 'create_wallet', leaving ambiguity about scope or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_account' and 'get_balance', the description lacks context on prerequisites, such as whether a wallet must exist or be selected, or how it relates to other 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 states it 'gets information' but doesn't describe if this is a read-only operation, requires authentication, has rate limits, or what happens if the ticker isn't found. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose without unnecessary words. Every part earns its place by specifying what information is retrieved and how, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return format (e.g., JSON structure), error conditions, or dependencies, leaving the agent with insufficient context for reliable use in a blockchain environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'ticker' parameter is a 'ticker symbol' used to retrieve token information like contract address and decimals. With schema description coverage at 0% (the schema only indicates 'ticker' is a required string), this compensates somewhat, but doesn't fully detail format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'information about a configured token', specifying it retrieves contract address and decimals by ticker symbol. It distinguishes from siblings like get_balance or get_transaction by focusing on token metadata rather than balances or transactions, though it doesn't 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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the token must be pre-configured), exclusions, or compare with sibling tools like get_token_allowance_evm for different token-related queries.
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 but lacks critical behavioral details. It doesn't disclose that this is a write operation requiring authorization, potential transaction fees, irreversible nature, or network-specific constraints. 'Send' implies mutation, but transparency 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, efficient sentence with zero waste. It's front-loaded with the core action and includes essential details (currency types, units) without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial transaction tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It misses critical context like error handling, return values, security implications, and integration with sibling tools, leaving significant gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying 'base units' for amount and clarifying token types, but doesn't explain parameter roles (e.g., tokenAddress optional for native currency) or format details beyond schema patterns. Baseline 3 as it partially addresses gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and resources ('native currency or an ERC20 token'), specifying the unit ('base units'). It distinguishes from siblings like 'approve_token_evm' or 'sign_raw_transaction' by focusing on direct transfers, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites like having sufficient balance or gas fees, or when to use 'approve_token_evm' for token approvals first. This leaves usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create and sign' implies a write/mutation operation, it doesn't specify whether this requires authentication, what permissions are needed, if it's idempotent, or what happens on failure. The description mentions 'expiresAt' as included in the certificate, but this isn't in the input schema, creating confusion rather than clarity about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create and sign a canonical certificate') and then lists components. There's no wasted verbiage, and it's appropriately sized for the tool's complexity. However, the inclusion of 'nonce' and 'expiresAt' not in the schema slightly reduces clarity without adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only 50% schema description coverage, the description is incomplete for a tool that performs a write operation (signing). It lacks details on authentication requirements, error handling, return values, or how the signed certificate is delivered. The mention of 'nonce' and 'expiresAt' not in the schema adds confusion rather than 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 50% (2 out of 4 parameters have descriptions). The description lists 'purpose, payload, domain, timestamp, nonce, and expiresAt' as included, but only 'purpose', 'payload', 'domain', and 'timestamp' are in the schema, with 'nonce' and 'expiresAt' missing. This adds some semantic context for the parameters that exist but introduces inconsistency. The description compensates partially for the schema's gaps but not fully.
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 ('Create and sign') and the resource ('canonical certificate'), making the purpose understandable. It also lists key components included in the certificate, which adds specificity. However, it doesn't explicitly differentiate this tool from sibling tools like 'sign_message' or 'sign_typed_data_evm', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'sign_message' and 'sign_typed_data_evm' that also involve signing operations, there's no indication of what distinguishes this certificate signing from those other signing operations. No prerequisites, exclusions, or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is to 'Get', implying a read operation, but does not specify if it requires authentication, has rate limits, returns specific data formats, or handles errors. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It does not explain what 'chain' refers to (e.g., blockchain identifier), what data is returned, or any behavioral aspects like error handling. For a tool with zero structured metadata, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here, but it could have clarified what 'chain' means (e.g., blockchain network) to enhance semantics, though not strictly required.
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 the target resource ('chain of the wallet'), making the purpose understandable. However, it does not differentiate from siblings like 'get_account' or 'get_balance', which also retrieve wallet-related information, leaving some ambiguity about what specifically distinguishes this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_account' and 'get_balance' that might retrieve related wallet data, there is no indication of context, prerequisites, or exclusions for selecting 'get_chain'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches a 'suggested' fee, implying it's informational/read-only, but doesn't clarify if it's real-time, cached, requires authentication, has rate limits, or what happens on errors. This leaves significant gaps for a tool interacting with a blockchain network.
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 directly states the tool's function without unnecessary words. It's front-loaded with the core action ('Fetch a suggested priority fee') and efficiently adds context ('for including a transaction in the next blocks from VeChain mainnet'). Every part 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?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate but lacks depth. It explains what the tool does but not how it behaves (e.g., response format, error handling, network dependencies). For a blockchain fee tool, more context on reliability or data freshness 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied as it efficiently handles the zero-parameter case without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('suggested priority fee'), specifying it's for VeChain mainnet transactions. However, it doesn't explicitly differentiate from sibling tools like 'get_transaction' or 'get_block', which also fetch blockchain data but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal context ('for including a transaction in the next blocks'), but offers no explicit guidance on when to use this tool versus alternatives (e.g., other fee estimation tools or sibling tools like 'get_transaction'). There's no mention of prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what information is retrieved but doesn't describe response format, error conditions, rate limits, authentication requirements, or whether this is a read-only operation. The description is functional but lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and immediately clarifies the key parameter. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'information about a VeChain block' includes, how the expanded/raw flags affect output, or provide any context about the data structure returned. The agent would need to guess about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing comprehensive parameter documentation. The description adds minimal value beyond the schema by mentioning the revision parameter accepts 'block ID, number, or keywords' but doesn't provide additional context about when to use each format or the implications of the expanded/raw flags.
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 ('Retrieve information') and resource ('a VeChain block'), with precise scope details about the revision parameter (block ID, number, or keywords). It distinguishes from sibling tools like get_transaction or get_account by focusing exclusively on block data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the revision parameter explanation (e.g., 'best | justified | finalized'), but provides no explicit guidance on when to use this tool versus alternatives like get_transaction for transaction details or get_chain for chain-level data. No prerequisites 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While it describes the basic read operation, it doesn't mention rate limits, authentication requirements, error conditions, or what specific account information is returned. For a read tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second sentence efficiently explains the optional parameter. No wasted words or unnecessary elaboration.
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 read tool with no output schema and no annotations, the description is adequate but incomplete. It covers the basic purpose and parameters but doesn't describe what information is returned about the account/contract, which is a significant gap given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema by mentioning the revision options and default behavior, but doesn't provide additional semantic context about parameter usage or implications.
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 information') and target resource ('VeChain account/contract by address'), distinguishing it from sibling tools like get_balance or get_address. It precisely defines what the tool does without being vague or tautological.
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 by mentioning the optional revision parameter, but doesn't explicitly state when to use this tool versus alternatives like get_balance or get_address. It provides some context about the revision parameter but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states the action and effect ('sets allowance to 0'), it doesn't mention transaction requirements (gas fees, network confirmation), permission needs, reversibility, or what happens on failure. For a blockchain write operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and effect. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a blockchain write operation with no annotations and no output schema, the description is incomplete. It lacks information about transaction behavior, error conditions, return values, and practical constraints like gas estimation or network requirements that are essential for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't explicitly name parameters, but with 0% schema description coverage, it effectively explains both parameters' purpose: 'tokenAddress' identifies the ERC20 token and 'spender' identifies the entity whose approval is being revoked. This adds meaningful context beyond the bare schema patterns.
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 ('revoke approval'), target resource ('ERC20 token'), and effect ('sets allowance to 0'). It distinguishes itself from sibling tools like 'approve_token_evm' by focusing on revocation rather than granting approval.
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 needing to remove token approval, but doesn't explicitly state when to use this tool versus alternatives like 'get_token_allowance_evm' for checking current allowances or 'approve_token_evm' for granting approval. No guidance on prerequisites or exclusions 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 full burden. It discloses some behavioral traits like handling pending transactions (meta may be null) and pinning to specific blocks, but doesn't cover important aspects like rate limits, authentication requirements, error conditions, or response format details. It provides basic operational context but lacks comprehensive 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 perfectly front-loaded with the core purpose first, followed by three concise optional features. Every sentence earns its place by providing distinct, valuable information without redundancy. The structure is logical and efficient with zero 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?
Given no annotations and no output schema, the description should do more to compensate. While it covers the basic operation and parameter implications, it lacks information about return values, error handling, rate limits, or authentication requirements. For a 4-parameter tool with no structured output documentation, this leaves significant gaps in 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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context by explaining the implications of optional parameters: 'pending txs (meta may be null)', 'return raw hex', and 'pin to a specific head block'. This provides semantic understanding beyond the schema's technical descriptions, elevating the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('a VeChain transaction by its ID'), distinguishing it from siblings like get_block or get_account which retrieve different blockchain entities. It precisely identifies what this tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through optional parameters (e.g., 'include pending txs'), but doesn't explicitly state when to use this tool versus alternatives like get_block for block data or get_balance for account information. No explicit when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses critical behavioral traits: the default behavior (private key redacted), how to override it (includeSecret=true), and security warnings ('handle with care'). It also specifies the derivation path and coin type, adding valuable context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key details (derivation path, default behavior, override option). Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (cryptographic operations) and lack of annotations/output schema, the description is largely complete. It covers purpose, parameters, behavior, and security. A minor gap is the absence of explicit output details (e.g., response format), but this is mitigated by the clear behavioral disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter (wordlistSize), so the baseline is 3. The description adds meaningful semantics by explaining the parameter's effect on mnemonic length (12/15/18/21/24 words) and mentioning the default, which enhances understanding beyond the schema's enum and 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 specific action ('Generate a BIP-39 mnemonic and derive the account-level secp256k1 key') and resource (wallet/key). It distinguishes from siblings by focusing on wallet creation rather than operations like sending tokens or getting balances, making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to create a wallet with specific cryptographic details) and includes a caution about handling private keys. However, it does not explicitly state when not to use it or name alternatives among siblings, such as using existing wallet tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (search across documentation), what it returns (contextual content with titles and direct links), and the scope (VeChain Docs). It doesn't mention limitations like rate limits or authentication requirements, but provides solid operational context for a read-only search 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 perfectly concise and front-loaded. The first sentence establishes the core functionality, the second provides explicit usage guidelines, and the third describes the return format. Every sentence earns its place with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with no annotations and no output schema, the description provides excellent context. It clearly explains what the tool does, when to use it, what it searches, and what it returns. The only minor gap is the lack of output format details beyond 'contextual content with titles and direct links,' but this is reasonable given the tool's simplicity.
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 a single 'query' parameter clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., query syntax, examples, or search operators). This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('search across the documentation') and resources ('documentation, code examples, API references, guides'), distinguishing it from sibling tools which are all blockchain/transaction-related. It explicitly mentions the target domain ('VeChain Docs'), making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'Use this tool when you need to answer questions about VeChain Docs, find specific documentation, understand how features work, or locate implementation details.' It clearly differentiates this documentation search tool from all sibling tools which handle blockchain operations like transactions, balances, and signing.
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-mcp-server MCP server](https://glama.ai/mcp/servers/leandrogavidia/vechain-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/leandrogavidia/vechain-mcp-server)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/leandrogavidia/vechain-mcp-server'

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