Hedera Toolbox

Server Quality Checklist

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

Latest release: v3.4.5
Disambiguation4/5
Most tools have clearly distinct purposes across six modules (account, contract, governance, HCS, identity, token), with minimal overlap. However, some HCS tools like hcs_monitor and hcs_query could be slightly ambiguous in scope, though descriptions help differentiate them.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout (e.g., account_info, contract_analyze, token_monitor), with clear and predictable naming conventions across all 20 tools. No mixing of styles or deviations observed.
Tool Count3/5
With 20 tools, the count is borderline high for a single server, potentially overwhelming for agents. However, it's organized into six modules, which mitigates some complexity, but still feels heavy compared to typical well-scoped servers.
Completeness5/5
The tool set provides comprehensive coverage across Hedera blockchain operations, including account management, contract interactions, governance, HCS, identity, and token analysis. Each module offers a full lifecycle of tools from monitoring to deep analysis, with no obvious gaps for the domain.
Average 3.9/5 across 16 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the cost (0.1 HBAR) which is useful context, but doesn't describe what 'monitor' actually returns, whether it's real-time or historical data, rate limits, authentication requirements beyond the API key, or what constitutes 'unusual' patterns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve a purpose - one describing the monitoring function, one stating the cost. There's no wasted verbiage, though it could be slightly more 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?
For a monitoring tool with no annotations and no output schema, the description is incomplete. It doesn't explain what format the monitoring results take, what time periods are covered, how 'whale movements' are defined, or what constitutes the returned data structure. The cost information is helpful but insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema descriptions, so it meets 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 clearly states the tool monitors token transfer activity, whale movements, and unusual trading patterns for a Hedera token, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like token_analyze or token_price, which might have overlapping monitoring functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like token_analyze or token_price. It mentions a cost (0.1 HBAR) which implies a usage consideration, but doesn't specify when this monitoring tool is preferable to other analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully adds cost information ('Costs 0.50 HBAR'), which is valuable operational context. However, it doesn't describe what the analysis returns, potential rate limits, authentication requirements beyond the api_key parameter, or error conditions. The description provides some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences. The first sentence states the purpose and scope, while the second provides important cost information. There's no wasted language, though it could be slightly more structured with clearer separation of concepts.
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 4-parameter analysis tool with no annotations and no output schema, the description provides basic purpose and cost information but lacks critical details about what the analysis returns, error handling, or performance characteristics. The 100% schema coverage helps with parameters, but the overall context for using this tool remains incomplete given its analytical nature and lack of output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions analysis types but these are already in the enum, and it doesn't explain parameter interactions or provide usage examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Deep pattern analysis of an HCS topic' with specific analysis types listed (anomaly detection, trend analysis, entity extraction, risk assessment), providing a clear verb+resource combination. However, it doesn't explicitly differentiate from sibling HCS tools like hcs_audit_trail, hcs_monitor, hcs_query, hcs_verify_record, or hcs_write_record, 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. While it mentions the analysis types, it doesn't specify scenarios where this tool is preferred over other HCS tools or when it should be avoided. There's no mention of prerequisites or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about cost ('Costs 1 HBAR') and scope ('full chronological audit trail'), but lacks details on permissions, rate limits, error handling, or what the output looks like (e.g., format, pagination). This is adequate but has clear gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes a cost detail, with zero wasted words. It's 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.
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 is minimally complete: it states the purpose and cost. However, for a tool with 4 parameters and blockchain interaction, it lacks details on behavioral traits (e.g., response format, errors) and usage context, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain 'entity_id' types or 'topic_id' defaults in more detail), meeting the baseline for high 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 ('Retrieve') and resource ('full chronological audit trail for an entity from the Hedera blockchain'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'hcs_query' or 'hcs_monitor', which might have overlapping functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions a cost ('Costs 1 HBAR'), but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'hcs_query' or 'hcs_monitor', leaving the agent with minimal context for selection.
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 the cost (0.5 HBAR) and the screening purpose, but doesn't mention authentication requirements (though api_key parameter implies it), rate limits, response format, or what constitutes 'risk signals' beyond the listed categories. The description adds some behavioral context but leaves significant gaps for a tool with no annotations.
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 states the core purpose and includes important cost information. It's appropriately sized and front-loaded with the main functionality. The cost information at the end is valuable context that 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?
For a tool with no annotations and no output schema, the description provides basic purpose and cost information but lacks details about what the screening actually returns, how risk is assessed, or error conditions. Given the complexity of risk screening and absence of structured behavioral information, the description should do more to explain what users can expect from this 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 schema already documents both parameters fully. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Screen a Hedera account against on-chain risk signals' with specific risk categories listed (transaction patterns, counterparty risk, flagged accounts). It distinguishes from siblings like identity_verify_kyc by focusing on sanctions/risk screening rather than KYC verification. However, it doesn't explicitly contrast with all similar tools like identity_resolve.
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 'screen a Hedera account against on-chain risk signals' and mentions the cost (0.5 HBAR), which suggests when this tool might be appropriate. However, it lacks explicit guidance on when to use this vs. alternatives like identity_verify_kyc or identity_resolve, and doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost (0.5 HBAR), which is a behavioral trait, but does not cover other aspects like rate limits, authentication needs beyond the api_key parameter, or what happens if the proposal is invalid. The description adds some value but lacks comprehensive 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, efficient sentence that front-loads the purpose and includes key details (analytical components and cost). Every part earns its place with no wasted words, 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?
Given no annotations and no output schema, the description is moderately complete. It covers the purpose and cost but lacks details on output format, error handling, or prerequisites. For a tool with 4 parameters and analytical complexity, more context would be helpful, but it meets a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add any meaning beyond what the schema provides, such as explaining how parameters interact or their significance in the analysis. Baseline 3 is appropriate when the schema handles 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 specific action ('Deep analysis') and resource ('governance proposal'), listing the analytical components (voter sentiment, participation rate, token concentration, outcome prediction). It distinguishes from siblings like 'governance_monitor' by focusing on deep analysis rather than monitoring.
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 analyzing governance proposals with specific metrics, but does not explicitly state when to use this tool versus alternatives like 'governance_monitor' or 'contract_analyze'. It mentions a cost (0.5 HBAR), which provides some context but not clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: it's a read operation ('Check', 'Returns'), includes cost ('Costs 0.2 HBAR'), and output content ('KYC grant status and verification history'). It doesn't cover error cases, rate limits, or authentication details beyond the api_key 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?
Three sentences with zero waste: purpose, output, cost. Front-loaded with core functionality. Each sentence earns its place by adding distinct value (operation, returns, cost).
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 annotations and no output schema, the description covers purpose, output content, and cost adequately. However, it lacks context on error handling, typical response structure, or how to interpret KYC status results, leaving gaps 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?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no parameter-specific semantics beyond implying token_id is optional for multi-token checks. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Check'), target resource ('KYC status of a Hedera account'), and scope ('for one or more tokens'). It distinguishes from siblings like identity_check_sanctions (different check type) and identity_resolve (different identity operation).
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 KYC-enabled tokens), exclusions, or compare with siblings like identity_check_sanctions (sanctions vs KYC). The cost mention hints at usage but not decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behavioral traits: it's a paid operation ('Costs 1 HBAR'), involves computational analysis ('Deep analysis'), and outlines specific analytical aspects. However, it doesn't mention rate limits, error conditions, or output format details.
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 core purpose, followed by specific analysis components and cost, all in two efficient sentences with zero wasted words. Every element adds value 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 2-parameter tool with no annotations and no output schema, the description covers purpose and cost well but lacks details on output structure, error handling, or performance characteristics. It's adequate but has clear gaps given the analytical complexity implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter semantics beyond implying contract_id is for analysis, aligning with the baseline expectation when schema does the heavy lifting.
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 ('Deep analysis') and resource ('Hedera smart contract'), with detailed scope ('activity patterns, caller distribution, gas usage, risk assessment, and functional classification'). It distinguishes from siblings like contract_call (execution) or contract_read (simple query) by emphasizing comprehensive analysis.
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 in-depth contract analysis but lacks explicit guidance on when to choose this over alternatives like token_analyze or governance_analyze. It mentions cost ('Costs 1 HBAR'), which provides some context but doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost (0.05 HBAR), which is useful behavioral context. However, it lacks details on permissions, rate limits, error handling, or response format, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key details (default topic and cost) in a single, efficient sentence. Every element (status/metadata listing, default, cost) earns its place without redundancy or fluff.
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 is moderately complete: it covers purpose, default behavior, and cost. However, for a tool with 2 parameters and no structured output, it lacks details on response format, error cases, or operational constraints, leaving room for improvement in contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (api_key and topic_id) with descriptions. The description adds marginal value by mentioning the default for topic_id (HederaIntel platform topic), but does not provide additional syntax, format, or usage details beyond what the schema specifies.
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 verb ('Get') and resource ('current status and metadata of any HCS topic'), listing concrete attributes like message count, creation time, memo, and recent activity. It distinguishes from sibling tools like hcs_audit_trail, hcs_query, and hcs_write_record by focusing on status/metadata retrieval rather than historical analysis, querying, or writing operations.
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 obtain status and metadata for HCS topics, with a default to the HederaIntel platform topic. However, it does not explicitly state when not to use it or name alternatives among siblings (e.g., hcs_query for different query types), missing explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it returns AI-ranked messages and a summary, and mentions a cost (0.05 HBAR), which is valuable context. However, it lacks details on rate limits, error handling, or authentication needs beyond the api_key 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 front-loaded and concise, with two sentences that efficiently convey purpose, output, and cost without any wasted words. Every sentence adds value, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic completeness by stating what the tool does and its cost. However, for a tool with 4 parameters and no output schema, it could benefit from more details on return format or error cases, leaving some 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'natural language question' which aligns with the query parameter but doesn't provide additional semantics. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('query', 'returns') and resources ('HCS topic'), distinguishing it from siblings like hcs_monitor or hcs_audit_trail by focusing on natural language queries with AI-ranked results and summaries. It explicitly mentions what it does and what it returns.
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 usage context by specifying it's for querying HCS topics with natural language questions, but it does not explicitly state when to use this tool versus alternatives like hcs_understand or hcs_monitor. It provides some guidance through the cost mention, but lacks explicit when-not or alternative recommendations.
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 discloses key behavioral traits: it's a read operation (verification), involves blockchain interaction, and specifies a cost ('Costs 0.5 HBAR'), though it doesn't cover error handling or response 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?
The description is front-loaded with the core purpose in the first sentence and adds critical cost information in a second, efficient sentence 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?
For a verification tool with no annotations and no output schema, the description adequately covers purpose and cost, but lacks details on response format, error conditions, or blockchain-specific behaviors, leaving gaps in 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 the schema fully documents all three parameters. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high 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 states the specific action ('verify'), resource ('compliance record'), and purpose ('exists on the Hedera blockchain and has not been tampered with'), distinguishing it from siblings like hcs_write_record (creation) and hcs_audit_trail (history tracking).
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 verifying existing records, but lacks explicit guidance on when to use this tool versus alternatives like hcs_query or hcs_audit_trail, or prerequisites beyond the required parameters.
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 the tool's function and explicitly states a cost (0.1 HBAR), which is valuable operational context. However, it does not cover other behavioral aspects like rate limits, error conditions, or response 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?
The description is a single, well-structured sentence that efficiently conveys purpose, scope, and cost. Every element serves a purpose with no redundant information, making it highly 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?
Given the tool's moderate complexity (identity resolution with multiple data points), no annotations, and no output schema, the description is adequate but incomplete. It covers the core function and cost, but lacks details on output structure, error handling, or integration with sibling tools, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add any additional meaning or context beyond what the schema provides, such as format examples for 'account_id' beyond the schema's example. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Resolve') and resource ('Hedera account ID'), detailing what information is retrieved (account age, token holdings, transaction history, HCS-based identity records). It distinguishes from siblings like 'account_info' by focusing on identity resolution rather than basic account data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identity resolution, but does not explicitly state when to use this tool versus alternatives like 'identity_check_sanctions' or 'identity_verify_kyc'. It mentions a cost (0.1 HBAR), which provides some context but lacks clear guidance on exclusions or prerequisites.
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 and does well by disclosing key behavioral traits: it's a paid operation ('Costs 0.3 HBAR') and specifies the analysis scope. However, it doesn't mention rate limits, error conditions, or what 'deep analysis' entails beyond listed components.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every word earns its place: first sentence defines the action and scope, second sentence adds critical cost information 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 2-parameter tool with no annotations and no output schema, the description provides adequate context about what the tool does and its cost. However, it lacks details about return format, error handling, or what the 'risk scoring' entails, leaving gaps in completeness for an analysis 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%, so the schema already documents both parameters (api_key, token_id). The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Deep analysis of a Hedera token' with specific components listed (holder distribution, transfer velocity, liquidity, risk scoring). It distinguishes from siblings like token_monitor (monitoring) and token_price (price only) by focusing on comprehensive analysis.
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 token analysis needs but doesn't explicitly state when to use this vs. alternatives like token_monitor or token_price. It mentions the cost (0.3 HBAR), which provides some context about resource implications, but lacks explicit guidance on use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals key behavioral traits: the tool returns specific data types (proposals, deadlines, tallies), has conditional behavior based on topic_id presence, and discloses a cost ('Costs 0.1 HBAR'). It doesn't mention rate limits, authentication requirements beyond the api_key parameter, or error conditions, but provides substantial 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 efficiently structured in three sentences that each add value: purpose statement, parameter guidance, and cost disclosure. There's no wasted language, and the most critical information (purpose and topic_id impact) appears first.
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 tool with no annotations and no output schema, the description provides good coverage of what the tool does, how parameters affect behavior, and operational costs. It could be more complete by describing the return format in more detail or mentioning error cases, but given the 3-parameter complexity and 100% schema coverage, it's substantially informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds some semantic context by explaining the functional impact of topic_id ('without it, only token metadata is returned'), but doesn't provide additional meaning for api_key or token_id beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Monitor active governance proposals for a Hedera token or DAO' with specific outputs ('open proposals, voting deadlines, and current vote tallies'). It distinguishes from siblings like 'governance_analyze' by focusing on monitoring rather than analysis, but doesn't explicitly contrast with 'hcs_monitor' or 'token_monitor' which might have overlapping functions.
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 usage: 'Provide topic_id for best results — without it, only token metadata is returned.' This gives practical guidance on when to include the optional parameter. However, it doesn't explicitly state when to use this tool versus alternatives like 'governance_analyze' or 'hcs_monitor' from the sibling list.
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 communicates that this is a read operation (implied by 'Get'), discloses the cost ('Costs 0.05 HBAR'), and specifies the data returned (price, market cap, volume). However, it does not mention potential errors, rate limits, or authentication requirements beyond the api_key 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 front-loaded with the core purpose in the first sentence and efficiently adds cost information in the second. Both sentences earn their place by providing essential information without redundancy or unnecessary details.
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 moderate complexity (2 required parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, returned data, and cost, but could improve by addressing error handling, response format, or usage constraints relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (api_key and token_id). The description does not add any additional meaning or context about the parameters beyond what the schema provides, such as format examples for token_id or usage instructions for api_key.
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 the resources involved ('current price, market cap, and 24h trading volume for a Hedera token'), distinguishing it from sibling tools like token_analyze or token_monitor by focusing on real-time pricing data rather than analysis or monitoring.
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 token pricing data but does not explicitly state when to use this tool versus alternatives like token_analyze or token_monitor. It mentions the cost ('Costs 0.05 HBAR'), which provides some context for decision-making, but lacks explicit guidance on prerequisites or exclusions.
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 and effectively discloses key behavioral traits: it's read-only, non-transactional, gas-free, and specifies a cost ('Costs 0.5 HBAR'), which are crucial for an agent to understand operational constraints and implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states purpose and key behavior, the second adds cost information. It's front-loaded with essential details and 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.
Completeness4/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 mostly complete for a read-only contract call tool, covering purpose, behavior, and cost. However, it lacks details on error handling or response format, which could aid the agent in anticipating outcomes.
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 doesn't add meaning beyond the schema, such as explaining parameter interactions or usage examples, but doesn't need to compensate for gaps.
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 ('execute a read-only call'), target resource ('Hedera smart contract function'), and outcome ('return the result'), distinguishing it from siblings like contract_analyze or token_monitor that imply analysis rather than direct execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('read-only call... does not submit a transaction or cost gas') and distinguishes it from transactional calls, though it doesn't specify alternatives among siblings like contract_read or when not to use it for other purposes.
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 communicates that this is a read-only operation ('Read state... without executing a transaction'), discloses the cost ('Costs 0.1 HBAR'), and implies it's a query rather than a mutation. However, it doesn't mention rate limits, authentication requirements beyond the api_key parameter, or error 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 extremely concise (two sentences) and front-loaded with the core purpose in the first sentence. Every word earns its place: the first sentence defines the action and scope, while the second adds critical behavioral information (cost). There's no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (read operation with cost disclosure), no annotations, and no output schema, the description is reasonably complete. It covers purpose, behavioral traits (read-only, cost), and distinguishes from alternatives. However, without an output schema, it doesn't describe return values or error formats, leaving some gaps in full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (api_key and contract_id) with descriptions. The description doesn't add any additional meaning about parameters beyond what the schema provides, such as format examples for contract_id or usage context for api_key. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Read state from a Hedera smart contract') and lists the types of information retrieved ('contract info, bytecode size, recent activity, and storage details'). It distinguishes from potential siblings by explicitly stating 'without executing a transaction', which differentiates it from tools like contract_call that likely execute transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('get contract info, bytecode size, recent activity, and storage details without executing a transaction'), which implicitly suggests it's for read-only queries rather than state-changing operations. However, it doesn't explicitly mention when NOT to use it or name specific alternative tools among the siblings (e.g., contract_analyze, contract_call).
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 adds context beyond basic functionality: it specifies the cost ('Costs 2 HBAR'), the default behavior for topic_id, and the return values (record ID and transaction proof). This covers key operational traits like financial implications and output format, though it doesn't mention error handling 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 front-loaded with the core purpose and key details (returns, default topic, cost) in just three sentences, with zero waste. Each sentence earns its place by conveying essential information efficiently, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a blockchain write operation with no annotations and no output schema, the description does well by covering purpose, usage context, cost, and return values. However, it could be more complete by addressing potential errors, authentication needs beyond the api_key parameter, or linking to sibling tools for related tasks, leaving minor gaps in full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning the default for topic_id, but it doesn't provide additional syntax, format details, or examples. This meets the baseline of 3 for high 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 states the specific action ('Write a tamper-evident compliance record') and resource ('to the Hedera blockchain'), distinguishing it from sibling tools like hcs_audit_trail or hcs_query. It explicitly mentions the outcome ('Returns a record ID and transaction proof'), making the purpose unambiguous and distinct.
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 by stating it writes records to the blockchain, with an implicit alternative (using a custom topic_id vs. the default platform topic). However, it lacks explicit guidance on when not to use it or comparisons to siblings like hcs_verify_record, which might be for verification instead of writing.
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 and discloses key behavioral traits: it records a server-side event with a timestamp, specifies that it's free (no HBAR charged), and indicates it's a prerequisite for paid tools. However, it doesn't mention error conditions, response format, or idempotency, leaving some behavioral aspects uncovered.
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, followed by essential behavioral details. Every sentence earns its place: the first states the action, the second gives usage timing, the third explains server-side behavior, and the fourth clarifies cost. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does well by explaining the prerequisite nature, server-side recording, and cost. However, it doesn't describe what happens after confirmation (e.g., how paid tools become enabled) or potential error responses, leaving some contextual 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 description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema descriptions, maintaining the baseline score for high 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 states the specific action ('Confirm acceptance of the HederaIntel Terms of Service') and resource ('Terms of Service'), distinguishing it from all sibling tools which involve account, contract, governance, HCS, identity, or token operations. It precisely defines the tool's unique function within the server's ecosystem.
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?
It explicitly states when to use this tool ('Must be called before any paid tool will execute') and provides a clear prerequisite condition. It also specifies an alternative ('must match the version returned by get_terms'), giving complete guidance on usage context and dependencies.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's free to call, no API key is required, and it serves as an entry point for platform onboarding. However, it lacks details on rate limits, error handling, or response format, which would be helpful for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and platform context. It's efficient but includes some promotional content ('20 tools across 6 modules') that, while informative, slightly reduces conciseness. Most sentences directly support tool understanding.
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 tool with no annotations and no output schema, the description does a good job covering purpose, usage, and behavioral aspects. It explains the parameter's effect and onboarding process. However, it doesn't detail the return structure or potential errors, leaving some gaps in completeness for an agent invoking 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 has 100% description coverage, so the baseline is 3. The description adds value by explaining the optional parameter's purpose ('If provided, your current balance is returned') and providing context on account creation ('your Hedera account ID becomes your API key automatically'), which enhances understanding beyond the schema's technical details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get platform wallet address, pricing for all 20 tools in HBAR and USD, and your current balance') and distinguishes it from siblings by focusing on account information rather than contract analysis, governance, HCS operations, identity checks, or token functions. It provides a comprehensive overview of what data is retrieved.
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 explicitly states when to use this tool ('Use this tool first to discover how to fund an account and start using the platform') and provides clear alternatives for account creation ('To create an account automatically, simply send HBAR to the platform wallet'). It also mentions it's 'FREE to call — no API key required,' which helps differentiate it from tools that might require authentication.
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 and adds valuable behavioral context: it discloses cost ('FREE to call'), authentication requirements ('no API key required'), and output format ('Returns full legal JSON'). It doesn't mention rate limits or error behavior, but covers key operational aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences with zero waste: first states purpose, second provides usage rules and cost, third describes output. Every sentence earns its place by adding distinct, essential information.
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 0-parameter tool with no annotations or output schema, the description provides complete context: purpose, usage rules, cost, authentication, output format, and content details. It compensates for missing structured fields with clear natural language explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, maintaining focus on tool purpose and usage.
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'), resource ('machine-readable Terms of Service for the HederaIntel MCP Platform'), and scope ('full legal JSON'). It distinguishes from siblings by focusing on terms retrieval rather than account, contract, or token operations.
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?
Explicitly states when to use ('All agents MUST call this tool... before using any paid tool'), when not to use (implied: not for operational tasks), and names the alternative/next step ('call confirm_terms'). Provides clear prerequisites and sequencing guidance.
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:

[![hederatoolbox MCP server](https://glama.ai/mcp/servers/mountainmystic/hederatoolbox/badges/card.svg)](https://glama.ai/mcp/servers/mountainmystic/hederatoolbox)

Score Badge

Copy to your README.md:

[![hederatoolbox MCP server](https://glama.ai/mcp/servers/mountainmystic/hederatoolbox/badges/score.svg)](https://glama.ai/mcp/servers/mountainmystic/hederatoolbox)

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/mountainmystic/hederatoolbox'

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