hedera-mcp

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Every tool targets a distinct resource and action. The resource type (account, token, topic, contract, file, schedule, etc.) is included in the name, making it impossible to confuse one tool with another.
Naming Consistency5/5
All tools follow a strict 'hedera_verb_noun' pattern with lowercase and underscores. No deviations exist, ensuring predictable tool names.
Tool Count2/5
73 tools is far beyond the typical 3–15 range. While comprehensive, the sheer number makes the set feel heavy and could overwhelm agents, leading to slower selection.
Completeness5/5
The toolset covers nearly every operation on Hedera: accounts, tokens, topics, contracts, files, schedules, network queries, and extras like PRNG and transaction decoding. No obvious gaps exist.
Average 3.1/5 across 73 of 73 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 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 passing
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 provided, so description must disclose behavioral traits. It only states a confusing action without detailing effects, errors, or side effects. Missing critical information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the phrasing is awkward and unclear. Conciseness is not helpful if it sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters and no output schema or annotations, the description fails to provide any contextual information about return values, prerequisites, or behavior. It is entirely inadequate.
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%, and the description mentions no parameters. It adds no meaning beyond the schema. The two parameters (scheduleId, payerAccountId) are left completely unexplained.
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 it adds a signature to an existing scheduled transaction, but the phrasing 'Build (unsigned)' is confusing and unclear. It vaguely identifies the action but lacks specificity and precision.
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 hedera_create_schedule. No context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Build (unsigned) a file deletion' without disclosing what happens to the file, required permissions, or whether the deletion is immediate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but lacks necessary detail. It could be improved with minimal additional sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The description does not explain the result of building a deletion transaction or any side effects, leaving the agent uninformed about the tool's behavior.
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%, and the description adds no meaning to parameters. It does not explain what fileId or payerAccountId represent or how they should be used.
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 verb-resource: 'Build (unsigned) a file deletion.' It is clear but does not distinguish from sibling tools like hedera_delete_contract or hedera_delete_topic. The word 'build' is vague and could imply construction without execution.
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. No prerequisites, when-not-to-use, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions 'Build (unsigned)', which implies transaction creation but does not disclose mutation semantics, required permissions, or side effects. Critical behavioral 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but severely under-specified. It sacrifices completeness for brevity, leaving the agent without enough information to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The one-sentence description does not explain the output (an unsigned transaction), return format, or any behavioral impacts. This is critically incomplete for a transaction-building tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines tokenId and payerAccountId, but the description does not explain either parameter. With 0% schema description coverage, the description should clarify parameter roles and constraints but fails to do so.
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 'Build (unsigned) a token unpause.' This vaguely indicates it constructs an unsigned transaction to unpause a token, but it is not specific about what 'token unpause' entails and does not differentiate from the sibling tool hedera_pause_token. The verb 'Build' is generic and the phrase is not standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like hedera_pause_token or other token management tools. There are no usage constraints, prerequisites, or context hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Build (unsigned)' implying it returns an unsigned transaction, not executing it. With no annotations, this is minimal behavioral disclosure. No mention of required permissions, side effects, or return type. Does not contradict annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (one sentence) but omits critical information like parameter explanations and return value. Conciseness is achieved at the cost of helpfulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool builds an unsigned transaction (no output schema), the description should explain the return format, how to use the result, and token requirements. It is severely incomplete for an agent to correctly invoke and process the output.
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 descriptions cover 0% of parameters. The description adds no meaning for tokenId or payerAccountId—no format, purpose, or examples. Tool completely relies on developer to infer parameter semantics from context.
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 builds a token pause transaction that halts all transfers. It distinguishes from the sibling hedera_unpause_token by specifying 'pause' vs unpause. However, 'Build (unsigned)' is ambiguous about the output format.
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 freeze_token_account. No prerequisites (e.g., token must be unpaused) or when not to use it. The description lacks any usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description hints at a non-executing behavior ('Build (unsigned)'), but does not explicitly disclose that the tool returns an unsigned transaction requiring further signing. No annotations are present, so behavioral traits like required permissions or side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but this comes at the cost of essential information. It is front-loaded but fails to justify its brevity with adequate detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the description is severely incomplete. It does not explain what 'unsigned' means, the structure of the response, or how the tool fits into the workflow.
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%, and the description adds no meaning to any of the three parameters (tokenId, accountId, payerAccountId). The user must infer their purpose from the tool name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (unfreeze) and the resource (account for a token), distinguishing it from the sibling 'hedera_freeze_token_account'. However, the qualifier 'Build (unsigned)' may cause confusion without additional 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, such as when the account is frozen and needs to be unfrozen, or the prerequisite of having a freeze key. The description does not mention any conditions 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, the description carries full responsibility for behavioral disclosure. It only notes the admin key requirement but omits critical details such as irreversibility, effect on associated tokens, or that the returned transaction is unsigned and must be submitted separately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 8 words, but this conciseness sacrifices necessary information. It is front-loaded with the verb and resource, yet incomplete for fully understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns, the full lifecycle (agent must sign and submit externally), or any side effects.
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%, and the description fails to explain any parameter. It does not clarify that 'tokenId' is the token to delete or that 'payerAccountId' is an optional fee payer. This leaves the agent without essential context for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('build unsigned token deletion') and mentions a key requirement ('admin key to sign'), which clarifies the tool's purpose. However, it does not explicitly differentiate from sibling tools like 'burn_token' or 'wipe_token', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as burn or wipe. It lacks any context about prerequisites or scenarios where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the action. It does not state that this is a privileged operation requiring a KYC key, nor does it clarify that the output is an unsigned transaction. Since no annotations are provided, the description carries full burden and fails to add sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (9 words) and to the point, but it lacks structure or front-loading of key details. While concise, it sacrifices content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and 0% parameter coverage, the description is incomplete. It does not explain return values or the unsigned transaction nature, leaving the agent guessing about the tool's behavior.
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%, and the description does not explain any of the three parameters (tokenId, accountId, payerAccountId). The agent gets no additional meaning from the description beyond the schema's bare structure.
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 'Grant KYC' and the resource 'to an account for a token'. It distinguishes from sibling tools like hedera_revoke_kyc. However, the phrase 'Build (unsigned)' adds ambiguity about whether it creates an unsigned transaction, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as hedera_revoke_kyc or hedera_freeze_token_account. There is no mention of prerequisites like needing a KYC key or that the transaction must be signed.
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; description says 'unsigned' implying it doesn't execute the transfer, but doesn't explain further behavioral traits like signing requirement, fees, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure; could be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 5 parameters, description fails to mention return value (unsigned transaction) or prerequisites, leaving the tool's usage context incomplete.
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 coverage is 20% and description adds no parameter details beyond the schema; key parameters like tokenId, serial, toAccountId are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds an unsigned NFT transfer for a specific serial between two accounts, distinguishing it from fungible token or HBAR transfer siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 vs alternatives like hedera_transfer_token or hedera_approve_nft_allowance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only states 'Read' without confirming read-only nature, auth requirements, rate limits, pagination behavior, or what happens on error. This is a significant gap for a tool that accesses contract state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. However, it lacks sufficient detail to be considered well-structured; it is too minimal for the task 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 absence of annotations and output schema, the description should provide a thorough overview. It fails to explain what 'storage slots' are, how results are structured, or any constraints. The tool has 2 parameters and no output schema, so the description is incomplete.
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%. The description does not explain the meaning or usage of the two parameters (contractId and limit). The contractId parameter is implied by the tool's name, but limit's role in controlling result size or pagination is entirely unascribed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read', the resource 'a contract's current storage slots', and the source 'from the Mirror Node'. This distinguishes it from sibling tools like hedera_get_contract_info (which reads contract info) and hedera_query_contract (which can execute arbitrary queries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or explicit context for selection among the many sibling 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?
The description hints that the tool produces an unsigned transaction but does not explain what that means for behavior (e.g., does it return bytes? Side effects?). No annotations exist, so the description should carry full burden but fails to clarify output or mutation aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded, but it omits critical details. Every word earns its place, but the sentence is too sparse to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain what the tool returns, the role of each parameter, or the transactional nature (build vs execute). Highly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only mentions 'memo' implicitly. It does not explain the purpose of 'topicId' (which topic to update) or 'payerAccountId' (who pays). The description adds minimal 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 'Build (unsigned) an update' and the resource 'HCS topic memo'. It distinguishes this tool from siblings like hedera_create_topic and hedera_delete_topic by specifying it is for updating a memo.
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 (e.g., hedera_create_topic for new topics, hedera_get_topic_info for reading). No mention of prerequisites, signing, or submission steps.
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 provided. Description omits behavioral details: requires burn key, destroys tokens, creates an unsigned transaction needing signing/submission. Fails to disclose mutation and permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise but lacks structure. No bullet points or additional details. Could be improved with clear sections but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, no annotations, and the tool is a mutation, the description is incomplete. Missing workflow (unsigned transaction), permissions, effect on supply, and parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 50% (amount, serials described). Description adds no extra meaning; doesn't clarify that tokenId is the token to burn or that at least one of amount/serials is logically required. No explanation of exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it builds a burn of fungible amount or NFT serials. Verb 'Build (unsigned)' indicates transaction creation. Distinguishes from minting or transfer siblings, but could be more explicit about the transaction-building nature.
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 vs alternatives like hedera_wipe_token. No mention of prerequisites (e.g., token association, treasury role) or that burning reduces supply permanently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only says 'list recent blocks'. It does not explain pagination, default behavior, or any side effects (none expected). Inadequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly terse—one sentence lacking important details. While concise, it sacrifices completeness and does not earn its place by providing value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one optional parameter and no output schema, the description fails to explain what 'recent' means, how results are ordered, or what the response contains. The agent has insufficient context to use the tool reliably.
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?
The single parameter 'limit' has no description in the schema or tool description. With 0% schema description coverage, the description should compensate, but it offers no explanation of the parameter's purpose or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (recent blocks), and the source (Mirror Node). This distinguishes it from 'hedera_get_block' which presumably gets a single block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'hedera_get_block' or other query tools. Missing context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It notes the transaction is unsigned, but omits side effects (e.g., changes to file), error conditions, permissions required, or return format. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (14 words) and front-loads the key idea, but it lacks necessary details. While concise, it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient. It does not explain return values, error handling, or parameter usage, leaving significant gaps for an append operation.
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%, and the description provides no clarification on the purpose of 'fileId', 'contents', or 'payerAccountId'. The tool's purpose hints that 'contents' is the data to append, but no details on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends to an existing file and is designed for large bytecode. It distinguishes from sibling tools like create, update, and delete by specifying 'append' and 'larger than one transaction'. However, it could be more explicit about building an unsigned transaction.
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 large data that exceeds a single transaction limit, but does not explicitly state when to use it over alternatives (e.g., hedera_update_file). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states 'Build (unsigned)' implying the tool does not submit the transaction, but does not clarify side effects, authorization needs (signing), or that this is a potentially destructive operation (granting approval over all serials).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. However, it sacrifices informative content for brevity given 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?
With no output schema and a complex domain (Hedera blockchain), the description omits critical context: what 'unsigned' means operationally, return value, and how to use the built object. This is insufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only tokenId and spenderAccountId are required with no descriptions; ownerAccountId and payerAccountId have brief descriptions but still lack context). The description adds no parameter-level meaning beyond 'approve-for-all', leaving agents to guess formatting or defaults.
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 'Build' and resource 'NFT allowance for all serials of a collection', distinguishing it from sibling tools like hedera_approve_token_allowance (for specific serials) and hedera_approve_hbar_allowance (for HBAR). However, it could be more precise about the 'approve-for-all' concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like hedera_approve_token_allowance or hedera_approve_hbar_allowance. There is no mention of prerequisites (e.g., account association) 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?
The description discloses that the tool builds an 'unsigned' transaction, which is a key behavioral trait—it does not submit the transaction. However, with no annotations, it fails to disclose other critical behaviors such as requirements (e.g., account must be associated first), error states, or that the result is a transaction that needs signing. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the key fact that the tool builds an unsigned dissociation. While it is efficiently short, it omits essential details, preventing a 5. The structure is clean and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, and only 3 parameters with 0% schema coverage, the description is insufficient. It does not explain the return value (probably an unsigned transaction), no context on dissociation semantics, or any account prerequisites. This is a minimal viable description but leaves significant gaps for the agent.
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 coverage is 0%: the description does not explain any parameter. The schema itself is minimal (tokenIds, accountId, payerAccountId) and lacks semantic detail such as format of token IDs, meaning of accountId, or when payerAccountId is needed. The description adds no value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Build' and specifies the resource 'token dissociation', clearly indicating the tool creates an unsigned transaction to remove token associations. It distinguishes from the sibling tool 'hedera_associate_token' by name, but the description itself does not explicitly differentiate, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., hedera_associate_token for association, or other token management tools). There is no mention of prerequisites or common use cases, leaving the agent to infer from 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?
The description implies a read operation but does not disclose behavioral traits such as pagination, ordering, or what constitutes 'recent'. With no annotations provided, the description bears the full burden, yet it adds minimal behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is too brief to be fully helpful. While it avoids fluff, it sacrifices necessary detail, making it adequate but not well-structured for informative use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 0% schema description coverage, and many sibling tools, the description is incomplete. It fails to specify output format, limit behavior, or how results are ordered, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of the 'accountId' or 'limit' parameters. It only hints at 'account' but does not explain required format, defaults, or constraints, leaving the agent without guidance.
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 lists transactions for an account from the Mirror Node, specifying the verb 'list', the resource 'transactions', and the source 'Mirror Node', which distinguishes it from sibling tools like hedera_get_account_info (account details) and hedera_get_transaction (single transaction).
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 vs alternatives. For example, it does not clarify when to use this over hedera_get_transaction or hedera_get_contract_results, nor does it mention any prerequisites or contexts where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states a read-like operation. It does not disclose whether it is read-only, authentication needs, rate limits, pagination, or what 'recent' means. This is insufficient for safe tool selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It could be slightly more informative without losing conciseness, but it is not verbose.
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 absence of an output schema and annotations, the description lacks completeness. It doesn't explain the result format, pagination, time ordering, or error handling. For a tool that lists results from a mirror node, more context is needed.
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%, yet the description adds no parameter meaning. It doesn't explain what contractId format is valid or how limit affects results. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists recent execution results for a contract from the Mirror Node, using specific verb and resource. While it distinguishes from contract info or state tools implicitly, it doesn't explicitly differentiate from query_contract or execute_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as hedera_get_contract_info or hedera_query_contract. There is no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions listing serials from the Mirror Node but lacks details on pagination (limit is documented in schema but not explained), whether it returns metadata, or any rate limits. The description is too terse to adequately inform behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded. However, it sacrifices necessary detail for conciseness. Every sentence should earn its place; here, it is too brief to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero schema descriptions, the description is incomplete. It does not explain pagination, return format, or parameter meanings. A simple list tool still needs basic contextual details.
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%, so the description must compensate. It indirectly implies tokenId is the collection ID but does not explain the limit parameter or provide any parameter-specific guidance. The description adds no semantic value beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'minted NFTs (serials) of an NFT collection', and the source 'from the Mirror Node'. It distinguishes from sibling tools like hedera_get_nft_info (single NFT) and hedera_get_account_nfts (account-owned NFTs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it specify prerequisites (e.g., tokenId must be an NFT collection ID). It only implies usage by stating what it does, but no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Read... from the Mirror Node,' lacking details on authorization, cost, or side effects. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste. Efficiently communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should describe the return value. It does not mention what topic info includes (e.g., sequence number, running hash). Incomplete for a read operation.
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% and the description does not explain the 'topicId' parameter format or expected values. Adds no meaning 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 it reads HCS topic info from the Mirror Node, specifying the verb 'read' and the resource 'topic info'. It distinguishes from sibling tools that create, update, delete, or submit messages.
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 guidelines on when to use this tool versus alternatives, such as hedera_get_topic_messages or hedera_get_account_info. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It tells the tool produces an unsigned mint, which is crucial, but omits information about authentication, idempotency, or the nature of the output (e.g., transaction body).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. However, its brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of NFT minting (including the lack of output schema), the description fails to explain what the tool returns or how to use the result. It also does not mention required prerequisites like token association or treasury ownership.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description adds only an example ('IPFS CIDs') for metadata. It does not explain tokenId (the NFT collection) or payerAccountId, leaving the agent to guess their purposes.
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 builds an unsigned mint of NFTs with metadata, and the resource (NFTs) is explicit. It distinguishes from hedera_mint_fungible by specifying NFTs, but does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like hedera_mint_fungible or when not to use it. The term '(unsigned)' hints at a workflow but does not explain when one would want an unsigned transaction.
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 indicates a read operation ('list') but does not disclose pagination behavior, rate limits, error handling for invalid tokenIds, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action and resource. However, it lacks structural elements like bullet points or sections that could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only two parameters, yet the description does not explain the return structure or parameter details. It is insufficient for effective agent 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%, yet the description adds no explanation for the two parameters (tokenId, limit). It does not clarify that tokenId is required or that limit controls the result count and has a max of 100.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (accounts holding a token and their balances), and data source (Mirror Node). It distinguishes this tool from siblings like hedera_get_token_info or hedera_get_account_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like hedera_get_account_balance or hedera_get_token_info. It does not mention prerequisites, limitations, or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool builds an unsigned transaction, which is a key behavioral trait. However, with no annotations, it omits details about authorization requirements, side effects, or reversibility. The unsigned nature is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one phrase), which is concise but at the expense of completeness. It front-loads 'Build (unsigned)' but offers no structure or additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low schema coverage, the description leaves significant gaps. It does not explain return value, prerequisites, or the need to sign/submit after building. For a mutation tool, this is insufficient.
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 naming 'memo' and 'auto-association slots' corresponding to memo and maxAutomaticTokenAssociations parameters. However, accountId and payerAccountId are not elaborated beyond the schema, and payerAccountId's role remains unclear. With low schema coverage (25%), the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it builds an unsigned account update for memo and auto-association slots, which is specific and distinguishes it from other Hedera tools. However, the term 'Build (unsigned)' might imply it doesn't execute the update directly, which could be clarified further.
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 hedera_update_token or hedera_delete_account. The description does not 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?
Reveals that the result is unsigned ('Build (unsigned)'), implying it requires separate signing/submission. However, no annotations exist, and the description omits side effects, authorization requirements, or return structure.
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?
Single sentence, concise and front-loaded. No wasted words, but could accommodate slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is insufficient. It lacks context on what the output is (unsigned transaction?), how to use the result, or prerequisites like token association. Incomplete for a moderately complex operation.
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 covers only 40% of parameters with descriptions (amount, ownerAccountId). Tool description adds no explanation for parameters like tokenId, spenderAccountId, or payerAccountId. The description solely states the tool's purpose without parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that it builds an unsigned fungible-token allowance for a spender. Distinguishes from sibling hbar and NFT allowance tools by specifying 'fungible-token', but could be more explicit about building a transaction rather than executing.
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 hedera_approve_hbar_allowance or hedera_approve_nft_allowance. Lacks conditions, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Build (unsigned)', which hints at the need for signing, but does not explain the full lifecycle (signing, submission), side effects (topic creation), or requirements for keys. Key behaviors like immutability without adminKey are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the key concept 'Build (unsigned)' and the purpose. It is concise, but could be slightly longer to include critical behavioral info without becoming verbose.
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 creation tool with 4 parameters, no output schema, and no annotations, the description is too brief. It does not explain the return value (likely an unsigned transaction), the need for subsequent signing/submission, or any prerequisites. The complexity of topic creation (key roles, memo) is under-communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 3 of 4 parameters (memo, adminKey, submitKey) with useful details. The tool description adds no additional parameter information beyond the schema. The missing payerAccountId parameter has no description in either schema or tool description, leaving a gap.
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 specifies the verb 'Build', the resource 'new HCS topic', and the purpose 'ordered, timestamped messages'. It clearly distinguishes from sibling tools like hedera_update_topic, hedera_delete_topic, and hedera_submit_message.
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 hedera_submit_message, hedera_update_topic. It does not mention prerequisites (e.g., need for an existing account) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions 'unsigned' implying the transaction is built but not submitted, but doesn't clarify authorization requirements, side effects (e.g., contract removal), or what happens if balance is zero. Key behavioral traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently captures the core action and a key detail (balance transfer). It is front-loaded and free of fluff. However, it is perhaps too concise given the lack of annotations and schema documentation; a slightly longer description could improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only 33% parameter schema coverage, the description is insufficient. It does not explain the return value, errors, or the lifecycle of the contract after building the transaction. A deletion tool in Hedera requires more context about the transaction building process, such as signing and submission expectations.
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 33% (only transferAccountId has a description). The description adds meaning by linking 'transferring any balance' to transferAccountId, but fails to explain contractId or payerAccountId. This partial compensation merits a 3, as it adds some value beyond the schema but not enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Build (unsigned) a contract deletion, transferring any balance to an account,' which clearly indicates the verb ('Build') and resource ('contract deletion') and adds a key detail (balance transfer). It distinguishes from sibling tools like hedera_delete_token or hedera_delete_topic by specifying 'contract.' However, the term 'unsigned' could be clearer about the tool's role (e.g., does not execute).
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 hedera_delete_token or how it relates to other contract tools. There's no mention of prerequisites, context, or why one would choose this over other deletion 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?
No annotations provided. Description discloses that the tool builds an unsigned deletion (i.e., produces a transaction, not directly deleting) and requires admin key. Adds behavioral context but lacks details on side effects or limits.
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?
Single sentence, no fluff. Could be improved by front-loading the essential info (e.g., deletion of schedule, unsigned) but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description does not explain what the tool returns (e.g., unsigned transaction bytes) or how to proceed after building. Incomplete for reliable agent invocation.
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 has 0% description coverage, and description provides no explanation for parameters scheduleId or payerAccountId. Agent cannot infer their purpose or format from description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies action (build deletion) and resource (scheduled transaction), distinct from sibling tools like create or sign. However, 'Build (unsigned)' may imply it only prepares a transaction, not executes deletion, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'requires admin key' as a precondition. No explicit when-to-use or alternatives, but among siblings, only this tool deletes schedules, so context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool builds an unsigned transaction and blocks transfers, but omits important details: whether it requires a freeze key, whether the account must already be associated, and what happens to existing allowances or scheduled transactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), which aids readability. However, it is too brief for a tool that performs a sensitive financial operation. The 'Build (unsigned)' qualifier is front-loaded, but overall structure lacks sufficient detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about what the tool returns, what inputs are needed beyond the basics, and any side effects. It does not mention that the transaction needs to be signed and submitted, nor any restrictions on when freezing is allowed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage. The parameter names ('tokenId', 'accountId', 'payerAccountId') are self-explanatory, but the description adds no detail about their format, purpose, or constraints (e.g., tokenId in '0.0.x' format). The optional 'payerAccountId' is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Freeze an account for a token') and the effect ('blocks transfers'). It distinguishes itself from sibling tools like hedera_unfreeze_token_account and hedera_pause_token by specifying the freeze action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., pausing, wiping). No mention of prerequisites like token association, KYC, or key requirements. The term 'Build (unsigned)' hints at usage context but lacks actionable instructions.
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?
Discloses that the tool builds an unsigned transaction, implying no direct on-chain effect. However, with no annotations, it fails to mention permissions, reversibility, or what happens to the built transaction. Partial but missing key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise, but it sacrifices necessary detail. Could be slightly expanded without losing brevity.
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?
Missing key context: output format (transaction bytes?), how to submit the built transaction, and relationship to sibling tools. No output schema to compensate.
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 has 33% coverage (only amount described). Description adds no parameter details, leaving tokenId and payerAccountId unexplained. The low schema coverage is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as building an unsigned mint transaction for fungible tokens, distinguishing it from NFT minting. However, 'Build (unsigned)' could be more explicit about it being a transaction construction step.
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 hedera_burn_token or hedera_mint_nft. The description does not mention prerequisites, such as token association or existing supply.
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 provided, so description carries full burden. The term 'Build (unsigned)' conflicts with the tool name 'submit_message', causing ambiguity about whether the tool submits the message or just prepares it. No disclosure of network interaction, permissions, or signing requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is concise, though it could be slightly expanded to cover critical details without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a description that omits parameter guidance, behavioral traits, and return values, the tool is inadequately documented for an agent to use correctly. Essential context like the need for signing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description adds no parameter-level details beyond the general statement. It does not explain topicId, payerAccountId, or message format, leaving the agent reliant on the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build' and the resource 'message submission to an HCS topic', distinguishing it from sibling tools like hedera_create_topic or hedera_get_topic_info. It specifically targets HCS message submission.
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 guidelines on when to use this tool versus alternatives. It does not mention prerequisites (e.g., need an existing HCS topic) or when not to use it. The 'unsigned' hint is present but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Build (unsigned)' but does not explain what 'build' means operationally (e.g., returns a serialized transaction, requires subsequent signing), nor does it describe any side effects, permissions, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. It is front-loaded with the core action. However, it could include slightly more detail without sacrificing brevity.
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 presence of 5 parameters and no output schema, the description is insufficient. It does not clarify the return value, the fact that the tool does not execute the transfer, or how to use the result. Sibling tools offer similar operations but differentiation is lacking.
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?
With only 40% schema description coverage, the description does not add any parameter-specific details beyond what is in the schema. Critical parameters like tokenId, toAccountId, and payerAccountId lack semantic explanation.
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 specifies the verb 'Build', the resource 'fungible token transfer', and adds the qualifier 'unsigned', distinguishing it from related tools. It clearly identifies the action and scope of the 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?
No guidance on when to use this tool versus alternatives like hedera_transfer_nft or hedera_transfer_hbar. Prerequisites (e.g., token association) and scenarios are not 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?
The description notes that the tool builds an 'unsigned' update, which implies it does not submit to the network. However, it does not explain the implications (e.g., the transaction must be signed and submitted separately), nor does it disclose potential side effects, permissions required, or that contents are replaced entirely. No annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, which is efficient. However, it could front-load the key action more explicitly and add a brief sentence about usage to improve structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and the complexity of building an unsigned transaction, the description is incomplete. It does not describe the return value (the built transaction), execution prerequisites, or behavior for partial updates.
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?
With 0% schema description coverage, the description should compensate but only mentions 'contents and/or memo' while ignoring required parameter fileId and optional payerAccountId. It provides no format hints or constraints beyond what the schema property names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (build/update), the resource (file), and the scope (contents and/or memo). It distinguishes from siblings like hedera_create_file and hedera_append_file by specifying 'update' and 'replaces'.
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 (e.g., when to use hedera_create_file, hedera_append_file, or hedera_delete_file). It does not mention prerequisites, such as the file must exist, or that the tool only builds an unsigned transaction.
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 provided. Description mentions 'Build (unsigned)' but does not disclose if tokens are destroyed permanently, prerequisites like token association, or that it only creates a transaction requiring signing. Missing key behavioral details.
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?
Single concise sentence front-loading the verb. Could add more context without significant bloat, but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 0% schema descriptions, no annotations, and no output schema, the description is insufficient. Missing mutual exclusivity, unsigned nature implications, and output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, description does not explain parameters beyond their names. Implies mutual exclusivity of amount and serials but not explicitly stated. No added value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an unsigned wipe transaction for fungible amount or NFT serials from an account. Differentiates from sibling tools like burn, transfer, etc.
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 vs alternatives like hedera_burn_token. Only implied usage for wiping tokens from an account, lacking context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Read' suggesting no side effects, but does not disclose rate limits, cost, or what 'active' means. Minimal behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, efficiently conveying the core purpose. It is front-loaded but slightly overly terse, missing some context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks details on return values, pagination, error handling, and the definition of 'active'. It does not fully cover the needed context for a simple read tool.
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?
The schema has 0% description coverage for the single parameter 'accountId'. The description does not explain the expected format (e.g., shard.realm.num or alias) beyond the type string. No additional meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('account's active HBAR allowances'), and the source ('Mirror Node'). It distinguishes itself from sibling tools like 'hedera_get_account_token_allowances' by specifying 'HBAR (crypto)' allowances.
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 reading HBAR allowances but does not explicitly state when to use this tool versus siblings like 'hedera_get_account_token_allowances' or 'hedera_get_account_nft_allowances'. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavior. It mentions 'unsigned' implying it returns an unsigned transaction, but fails to detail permissions, side effects, or what happens if tokens already associated.
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 of 13 words, front-loaded with verb 'Build'. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param tool with no output schema and no annotations, the description is too sparse. It omits return value, prerequisites, and the significance of 'unsigned'.
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%, and description only indirectly explains tokenIds and accountId via context. payerAccountId is left unexplained. Minimal value added beyond field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Build (unsigned)' and resource 'token association', clearly distinguishing it from siblings like hedera_dissociate_token. It states the purpose: allowing an account to hold given tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or when-not-to-use. The description lacks context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the tool builds an unsigned deployment, but lacks details on permissions, side effects, failure modes, or that the bytecode must already be stored. This is insufficient for a mutation-like tool.
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 single sentence is concise and front-loaded with the key verb. However, it could be improved by adding context on output or next steps without being too verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return value (unsigned transaction), prerequisites (file with bytecode), and how to proceed (sign and execute). This is a significant gap for a tool that produces an intermediate artifact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so baseline is 3. The description does not add any additional meaning beyond the schema. It does not explain relationships between parameters or usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build') and resource ('contract deployment'), specifies it is unsigned, and references a sibling tool (hedera_create_file) for context, distinguishing it from execution tools like hedera_execute_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, such as mentioning it should be followed by hedera_execute_contract. The reference to hedera_create_file is helpful but not a complete usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Read ... from the Mirror Node', implying idempotent read-only behavior, but this is only implicit. With no annotations provided, the description carries the full burden, but it omits important details like whether authentication is needed, whether results are paginated, or what the response structure is.
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 very concise with a single sentence. However, it sacrifices necessary detail for brevity. It could include relevant context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description is minimally adequate: it states the operation and data source. However, it lacks output semantics, error behavior, and any differentiation from sibling tools. The absence of an output schema increases the burden on the description, which is not met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'accountId' is left undefined in both the schema (0% coverage) and description. The description does not clarify the expected format (e.g., Hedera ID, EVM alias, or public key), leaving the agent to guess. This is a significant gap for a required parameter.
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 specifies the verb 'Read' (or 'get' from the tool name), the resource 'account's active fungible-token allowances', and the data source 'Mirror Node'. It effectively distinguishes from sibling tools like 'hedera_get_account_allowances' (which likely covers all allowances) and 'hedera_get_account_nft_allowances' (NFT-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as 'hedera_get_account_allowances' or 'hedera_get_account_nft_allowances', nor does it mention any prerequisites or context for calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states 'Read' implying read-only, but does not disclose what happens on missing block, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential verb and object with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description provides the minimal needed to understand its function. However, it lacks details about return format or error behavior that could help an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter already described as 'Block number or hash'. The description adds no further 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 verb 'Read' and the resource 'a block by number or hash'. It distinguishes from the sibling 'hedera_get_blocks' (plural) by implying singular lookup, but does not 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?
The description offers no guidance on when to use this tool versus alternatives like 'hedera_get_blocks' or other read tools. It does not mention typical 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool 'Build(unsigned)' a transaction rather than executing it, and 'returns to its treasury' explains the effect. However, with no annotations, it fails to disclose prerequisites (e.g., association, balance) or side effects. Some behavioral context is added but incomplete.
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, front-loaded sentence with no wasted words. Includes key references (HIP-904) and action verb. Appropriate length for the 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?
Despite good purpose clarity, the description lacks critical context: prerequisites (must hold token?), relationship to other token operations, and output behavior. No output schema, and parameter semantics are weak, leaving the agent underinformed.
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?
The input schema has 3 parameters with only 33% coverage via descriptions (ownerAccountId). The tool description adds no parameter information, leaving tokenId and payerAccountId undefined beyond their types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Build (unsigned) a token rejection' and the outcome: 'returns an unwanted token to its treasury.' It references HIP-904 for standardization. Among many token-related siblings like hedera_transfer_token, hedera_dissociate_token, this tool's specific purpose is well-defined.
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 (e.g., dissociate or wipe). The description implies it's for 'unwanted' tokens but lacks when/why. No exclusions or context 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?
No annotations are provided, so the description carries the full burden. It introduces the key behavioral trait 'unsigned', indicating the file transaction is not submitted to the network. However, it does not explain what 'unsigned' entails (e.g., whether it returns a transaction object, how signing works) or any other behavioral aspects like destructive effects or permissions.
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, no wasted words. The first sentence states the function, the second provides a practical use case. Ideal length for a creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about return values (e.g., file ID, transaction ID) and prerequisites (e.g., account existence, signing requirements). For a tool with no output schema and no annotations, these gaps make it insufficiently complete for an agent to correctly invoke and interpret the result.
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%, with descriptions for 'key' and 'contents' but not 'memo' or 'payerAccountId'. The description adds context by mentioning 'unsigned' and the bytecode use case, but does not elaborate on the meaning or format of the undocumented parameters. Baseline 3 is appropriate given partial coverage and modest additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and resource ('new file'), and provides a concrete use case ('storing compiled contract bytecode before deployment'). It is clear and distinct from siblings like hedera_append_file or hedera_update_file, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions one use case but does not specify prerequisites, when not to use, or which sibling tools might be more appropriate.
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 full burden. It discloses that the tool builds an unsigned transaction and that a supply key is required to mint. However, it does not explain that the returned transaction must be signed and submitted separately, nor does it mention side effects, authorization needs, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The key information (builds NFT collection, unsigned, supply key required) is front-loaded. Could benefit from slightly more structure (e.g., listing required keys), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no output schema, and no annotations, the description is too brief. It does not explain the overall workflow (that the tool returns an unsigned transaction that needs to be signed), the role of keys (admin, supply, treasury), or the royalty fee configuration. For a complex tool, this is inadequate.
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 42% (low), and the description adds minimal semantic value beyond the schema. It only reinforces that supplyKey is required for minting. No explanation of key parameters like adminKey, treasuryAccountId, royalty fields, or their relationships. The description fails to compensate for the low 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 it builds a new NFT collection (non-fungible token) on Hedera Token Service (HTS) and identifies it as unsigned, distinguishing it from sibling tools like hedera_mint_nft, hedera_burn_token, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like hedera_create_fungible_token or hedera_mint_nft. Only mentions supply key requirement for minting, but lacks when-not-to-use or contextual triggers.
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 provided, and the description fails to disclose behavioral traits such as data source (Mirror Node), potential latency, or effects on the system – only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence; lacks detail but is appropriately brief for a simple list operation.
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?
No output schema, and the description does not indicate what fields are returned, pagination, or ordering – adequate but incomplete for a production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters; the tool description adds no additional meaning beyond listing NFTs per account.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and resource ('NFTs owned by an account') and distinguishes from sibling tools like hedera_get_nft_info or hedera_get_token_nfts.
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; no context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Read from Mirror Node', which implies a non-destructive query, but fails to disclose rate limits, authentication needs, or data freshness. With no behavioral details beyond the verb, transparency is low.
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 that efficiently states the tool's purpose and key returned fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is mostly adequate but missing parameter format guidance and differentiation from sibling read tools. The mention of specific return fields adds value, but the lack of parameter semantics leaves a gap.
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?
The single parameter contractId has no description in the schema (0% coverage). The tool description does not explain its format (e.g., '0.0.12345') or constraints. It only mentions return fields, leaving the parameter's meaning entirely to the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'contract info from Mirror Node', listing specific fields (admin key, bytecode metadata, EVM address). It distinguishes from siblings like hedera_query_contract and hedera_get_contract_results.
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 reading contract metadata but does not explicitly state when to use this tool versus alternatives like hedera_query_contract or hedera_get_contract_results. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool builds an unsigned transaction, which is a key behavioral trait. However, it omits safety considerations (e.g., mutation requires KYC key) and does not specify whether it is destructive or affects account status beyond KYC.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the action and including the unsigned note. It is efficient but could be structured to place the 'Build (unsigned)' qualifier more effectively (e.g., at the end).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool being a state-changing operation, the description does not specify the return value (unsigned transaction) or any prerequisites (e.g., KYC key, token KYC status). It is incomplete for an agent to fully understand the tool's behavior and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explain the parameters beyond their names. The optional 'payerAccountId' is not clarified, and format requirements (e.g., token ID as '0.0.1234') are missing, leaving the agent without sufficient detail to correctly fill parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Revoke KYC' and the resources 'from an account for a token', distinguishing it from the sibling tool 'hedera_grant_kyc'. The inclusion of 'Build (unsigned)' adds context about the tool's behavior without obscuring the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'hedera_grant_kyc' or prerequisites (e.g., KYC key ownership, token association). The description lacks explicit exclusions or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It indicates a read operation but does not disclose any specific behaviors like rate limits, permission requirements, or what 'active' means. It minimally states the source ('Mirror Node') but lacks detail beyond that.
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 of 15 words, front-loading the action ('Read'). Every word contributes essential information 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 output schema and no annotations, the description covers the basic purpose and source but omits details like return format, pagination, or explanation of 'active.' It is minimally sufficient for a simple read tool but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the sole parameter accountId. The description adds meaning by implying accountId is the account whose allowances are read, but does not provide format, constraints, or examples. For a single obvious parameter, this is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Read an account's active NFT (approve-for-all) allowances from the Mirror Node,' which clearly identifies the verb (Read), resource (account's NFT allowances), and source (Mirror Node). It distinguishes from sibling tools like get_account_allowances (broader) and get_nft_info (individual NFT) by specifying NFT approve-for-all allowances.
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, no exclusions, no prerequisites, and no context about when not to use it. It simply describes what it does, leaving the agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates read-only operation, but lacks details on Mirror Node data freshness, rate limits, or response structure. Without annotations, more transparency would be beneficial.
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, 15 words, front-loaded with key information. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on return value (array of transfers), pagination, or error conditions. No output schema to compensate, leaving the agent underinformed.
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?
Description mentions 'specific NFT serial' and 'transfer/mint history' hinting at parameters, but does not explicitly describe tokenId format or serial constraints. With 0% schema description coverage, it fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads transfer/mint history of a specific NFT serial from the Mirror Node, using a specific verb and resource. It distinguishes from sibling tools like hedera_get_nft_info (current info) and hedera_get_token_nfts (list of NFTs).
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. For example, it does not explain when to prefer this over hedera_get_nft_info or other history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral context. It only states the tool finds accounts, implying a read-only query, but lacks details on limitations, rate limits, or the meaning of 'controlled by'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the tool's purpose with no unnecessary 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?
The description is adequate for a simple query tool but lacks information about the output format (e.g., list of account IDs) and potential pagination. Given no output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter, including format hints (hex/DER). The tool description adds little beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'accounts controlled by a given public key from the Mirror Node'. It distinguishes from sibling tools like get_account_info or get_account_by_evm by specifying the search key type.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, such as other account query tools, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the transfer is unsigned and requires multiple signatures before execution, but lacks important behavioral details such as expiration time, execution triggers, fee implications, or consequences if not fully signed. With no annotations, the description should provide more context about the tool's behavior and lifecycle.
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 front-loads the key action and concept. Every word contributes meaning without redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multi-signature flow, no output schema), the description is too brief. It omits details about return value (e.g., schedule ID), prerequisites (e.g., valid inner transfer), and execution model. The description is incomplete for an agent to use the tool effectively without additional 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?
With 71% schema description coverage, the schema already documents most parameters. The tool description adds minimal additional meaning beyond 'wraps an inner transfer'. While two parameters (memo, payerAccountId) lack schema descriptions, the tool description does not compensate for them, keeping the score at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned scheduled HBAR transfer, explaining that it wraps an inner transfer for multi-party signing. This distinguishes it from immediate transfer tools like hedera_transfer_hbar and signing tools like hedera_sign_schedule.
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 use when multiple parties need to sign before execution, but does not explicitly contrast with alternatives (e.g., when to use hedera_transfer_hbar instead) or provide when-not-to-use guidance. The implied usage is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the 'unsigned' nature of the built transaction, which is a key behavioral trait, but does not fully describe implications such as irreversibility, required authorization, or potential errors. Additional context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It efficiently communicates the core purpose and action.
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 potentially dangerous operation (account deletion), the description is minimal. It lacks safety context, prerequisites, and details about the unsigned transaction output. Without annotations or an output schema, more information is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes accountId and transferAccountId with simple labels. The tool description adds no extra parameter guidance. With 67% schema coverage, the description does not compensate for the undocumented payerAccountId parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build an account deletion') and the critical behavior ('transferring the remaining balance to another account'). It distinguishes itself from sibling deletion tools by specifying the resource and the balance transfer aspect.
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 hedera_update_account or hedera_transfer_hbar. It does not mention prerequisites or contraindications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly indicates a read-only operation via 'Read' and mentions the data source (Mirror Node) and expected fields. However, it does not disclose potential behaviors like rate limits, caching, data recency, or any other side effects. The description is minimally adequate.
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 starts with the action and resource. No redundant words. However, it could be slightly improved by incorporating basic parameter explanations without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description is the sole source for output expectations. It lists owner, metadata, serial but omits other potential fields and doesn't specify structure or format. For a read tool with only 2 parameters, more context is needed to set complete expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate but fails to. It does not explain what tokenId or serial represent or provide any format hints. While parameter names are self-explanatory, the description adds no context about expected values (e.g., token ID format, serial range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and specifies the resource 'a specific NFT's info' with examples of data returned (owner, metadata, serial). It clearly distinguishes from sibling tools like hedera_get_token_nfts (list) and hedera_get_nft_history (history), making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs information about a single NFT with known tokenId and serial, but it does not explicitly state when to use this tool versus alternatives like hedera_get_token_nfts or hedera_get_nft_history. No explicit 'when not to use' or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation via 'Read' and specifies the source, but does not disclose potential rate limits, data freshness, or authentication requirements. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clean sentence, front-loaded with the verb, and every word adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should describe the return. It lists key fields (type, supply, keys, custom fees) but omits others like owner or metadata. Adequate for a simple read, but could be more thorough.
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 coverage is 0% and the description adds no information about the single parameter 'tokenId'. The parameter name is self-explanatory, but the description should specify format expectations (e.g., '0.0.1234'). This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Read'), resource ('token info'), and lists key fields (type, supply, keys, custom fees). It also mentions the source ('Mirror Node'), effectively distinguishing it from sibling tools like hedera_get_token_balances or hedera_get_nft_info.
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?
While the description implies a read-only query, it provides no explicit guidance on when to use this tool versus alternatives (e.g., hedera_get_token_balances for balances). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States it builds an unsigned transaction and auto-associates recipients, but lacks details on permissions, side effects, or further steps. With no annotations, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 13 words, efficient and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and auto-association, but lacks output format (e.g., returns unsigned transaction bytes) and error cases. No output schema to rely on.
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?
Description adds no parameter-specific meaning; the schema already covers 'amount' and 'fromAccountId'. With 40% schema coverage, the description should compensate but does not explain tokenId or toAccountId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned fungible-token airdrop and highlights the key auto-association feature. It distinguishes from sibling tools like hedera_transfer_token or hedera_associate_token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like hedera_transfer_token. Does not mention prerequisites or use cases.
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?
The description notes the tool builds an unsigned transaction, implying no side effects, but with no annotations provided, it lacks disclosure of required permissions, signing requirements, or other behavioral traits. Adds moderate context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that efficiently conveys the tool's purpose without redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-building tool with no output schema, the description is minimal. It lacks context on the return value (the unsigned transaction), next steps (signing/submission), and related concepts like approval limits. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75%), and the description does not add new meaning beyond the schema. The description simply restates the purpose without enriching parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned HBAR allowance transaction, specifying the action (build), resource (HBAR allowance), and participants (owner, spender). It distinguishes from sibling allowance tools by specifying 'HBAR'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like hedera_approve_token_allowance or hedera_approve_nft_allowance. It does not mention prerequisites, such as the owner account must exist or the need for owner authorization.
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 provided. Description only states basic purpose, omitting details like pagination, rate limits, or output format. Minimal transparency beyond the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no extraneous words. Front-loaded with purpose. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, description hints at output (list of nodes and stake) but does not specify structure or potential limitations. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so description adds no param info. Baseline 4 as schema coverage is 100% and no param details needed. The mention of 'from the Mirror Node' provides contextual source but is not parameter-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'network's consensus nodes and stake' with source 'Mirror Node'. Distinguishes from sibling tools like hedera_get_network_stake which likely focuses on overall stake.
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 such as hedera_get_network_stake or other network queries. Simple tool but lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It adds the detail about decoding base64 payloads, but does not disclose whether the operation is read-only, requires permissions, how 'recent' is defined, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, with zero unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal. It explains the purpose but lacks details on usage, limitations, and expected results, leaving the agent without critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (topicId lacks description). The tool description adds no additional meaning for the parameters beyond what the schema provides, failing to compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'recent messages from an HCS topic', and adds a specific detail about decoding base64 payloads, making it distinct from sibling tools that manage topics or other Hedera operations.
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 reading topic messages but provides no explicit guidance on when to use this tool versus alternatives like hedera_get_topic_info or context about prerequisites or limitations.
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 provided; description only states 'state-changing' (implied destructive) and 'unsigned' (needs signing). Missing behavioral traits: requires gas, may revert, needs signing, output is an unsigned transaction to be submitted. Incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with key info. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 params, no output schema, and no annotations, description lacks details on return value (unsigned transaction), next steps (sign and submit), and potential failures. Incomplete for a complex 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?
Description adds meaning beyond schema by explaining two usage patterns: structured (abi+functionName+args) vs raw (functionParametersBase64). Schema only lists properties; description gives method selection guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Build (unsigned) a state-changing contract call' – a specific verb and resource, clearly distinguishing from sibling tools like hedera_query_contract (read-only) and hedera_deploy_contract (deploy vs call).
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?
Description implies two encoding modes (abi vs raw), but lacks explicit guidance on when to use this tool vs siblings (e.g., state-changing vs read-only). No mention of when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions 'via the Mirror Node,' hinting at a read operation, but does not disclose idempotency, authorization requirements, error behavior (e.g., if address not found), or any side effects. This is insufficient 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, direct sentence with no redundant words. It efficiently conveys the core functionality without requiring elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description is mostly complete. However, it could optionally hint at the output format (e.g., 'returns account ID and balance') to give the agent full context. Nonetheless, given the tool's simplicity, the description is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the evmAddress parameter as '0x-prefixed EVM address' with 100% coverage. The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Resolve a Hedera account' from a specific input ('0x EVM address') via a specific method ('Mirror Node'). This verb+resource+scope formulation is precise and distinguishes it from sibling tools like get_account_info which use account IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an EVM address and need the corresponding Hedera account, but it does not explicitly state when to use this tool versus alternatives (e.g., get_account_info for ID-based lookup) or when not to use it. No usage exclusions or context cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation from the Mirror Node, implying no state modification. However, it does not detail data freshness, rate limits, or public access nature. The behavioral disclosure is basic but adequate given 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?
Single sentence, 13 words, efficient. Front-loads purpose and lists key fields. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, source, fields. Lacks expected output format or structure, but for a simple read tool with one parameter, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description does not add meaning beyond the schema's 'Account id or EVM address'. No extra context or constraints provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly states the resource 'full account info' listing key fields like key, balance, memo, auto-renew, associations. It distinguishes this tool from siblings like hedera_get_account_balance which only retrieves balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when to prefer this over hedera_get_account_balance or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal, only stating it reads the exchange rate. With no annotations, behavioral traits like rate limits, caching, or error handling are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose.
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?
Despite the absence of an output schema and annotations, the description is sufficient for a simple read tool with no inputs. However, a hint about the output format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the description adequately covers the tool's purpose. No parameter information is needed beyond what the schema provides (empty).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read', the resource 'current HBAR↔USD exchange rate', and the source 'Mirror Node'. It distinguishes from sibling tools that retrieve other information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does without any context about when it is appropriate.
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?
The description discloses the key behavioral trait 'unsigned', indicating the tool does not execute the transfer. However, with no annotations, it lacks details on auth, fees, or what happens with the built transaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core function. It could be slightly more expansive but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with no output schema, but it would benefit from mentioning what the output is (e.g., an unsigned transaction) and that signing is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so parameters are mostly defined in the schema. The description does not add extra context beyond what the schema provides, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned HBAR transfer from one account to another, distinguishing it from sibling tools like hedera_transfer_token and hedera_transfer_nft by specifying 'HBAR'.
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 HBAR transfers but does not explicitly mention when to use this tool versus alternatives (e.g., hedera_transfer_token) or any prerequisites.
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?
The description discloses two key behaviors: the tool returns an unsigned transaction ('Build (unsigned)') and that the treasury defaults to the payer. However, with no annotations, it lacks details on permissions, side effects, or what happens with conflicting parameters. It's adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no fluff. The most critical information (what the tool does, the treasury default) is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, no output schema, no annotations), the description is minimal. It covers the essential purpose and a key default, but doesn't explain the lifecycle of the unsigned transaction (e.g., need for signing/submission) or the role of keys. Schema descriptions compensate somewhat, but overall completeness is just adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (88%), and the description adds value by specifying the default for treasuryAccountId ('defaults to payer'), which is not in the schema's parameter description. It avoids repeating schema information, thus providing a small but meaningful enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Build), the resource (new fungible token), and the context (HTS, unsigned). It distinguishes from sibling tools like hedera_create_nft_collection by specifying fungible token. The verb 'Build' and the qualifier '(unsigned)' are precise.
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 hedera_mint_fungible for increasing supply or hedera_create_nft_collection for NFTs. No exclusions or prerequisites are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only says 'Read,' implying idempotence, but lacks details on authorization needs, rate limits, or what 'records/results' includes. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear and to the point, with no unnecessary words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one parameter) and no output schema, the description is minimally adequate. However, it lacks details on what the output contains (records/results ambiguous) and does not compensate for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the one parameter (transactionId) with examples, so the description adds no extra meaning. Baseline 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a transaction's records/results from the Mirror Node by transaction id.' It specifies the resource (transaction), action (read), and distinguishes it from sibling tools that focus on other resources (e.g., accounts, tokens).
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 clearly indicates when to use this tool (to read a transaction by ID). However, it does not explicitly state when not to use it or provide alternatives, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden. It discloses the transaction is unsigned, which is important behavioral info, but does not detail side effects, costs, or return values. Some transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no extraneous information. The main purpose is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with two optional parameters and no output schema, the description covers the core purpose and the optional bound. However, it fails to explain the 'payerAccountId' parameter or the return format (e.g., the transaction type). It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with only 'range' described. The description adds meaning to 'range' by stating it bounds the result to [0, range), but provides no additional semantics for 'payerAccountId', leaving its purpose unclear beyond the schema name.
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 builds a pseudo-random number generation transaction, specifying it is native on-chain RNG. This verb-resource combination uniquely distinguishes it from all sibling tools which deal with tokens, accounts, contracts, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating random numbers optionally bounded by a range, but it does not provide explicit when-to-use or when-not-to-use guidance, nor alternatives. The context signals show no exclusions, but the description lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation through 'decode into a summary', but does not explicitly state that it has no side effects. This is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and purpose, with no wasted words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple decode tool with one parameter and no output schema, the description covers input format, purpose, and output type. It could mention that it does not modify state, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the single parameter 'transactionBase64'. The description adds minimal extra context ('e.g. one built by this server'), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes a base64 transaction into a human-readable summary, specifying the input format and its benefit for review before signing. This distinguishes it from sibling tools that create, update, or query entities.
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 mentions use for review before signing, providing a clear context, but does not explicitly state when not to use it or suggest alternatives. Given the many sibling tools, this guidance is adequate but lacks depth.
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?
The description discloses that the tool 'builds (unsigned)' a transaction, implying it does not execute. It also notes 'requires admin key'. With no annotations, this provides basic behavioral context but omits details like irreversibility or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 10 words effectively conveys the core purpose and key condition (admin key). No redundancy or 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 the tool's simplicity, the description covers the basic function and a key prerequisite. However, it does not mention side effects (e.g., topic becomes immutable) or error scenarios, leaving some gaps for an 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?
The input schema has 0% parameter description coverage and the description does not explain the parameters individually. 'topicId' is inferable from the tool name, but 'payerAccountId' is unexplained, leaving the agent with insufficient parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deletion of an HCS topic) and the resource (HCS topic), distinguishing it from sibling tools like create, update, or get topics.
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 mentions that the tool 'requires admin key', indicating a prerequisite. However, it does not specify when to use this tool over alternatives or provide explicit 'when not to use' guidance.
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 clearly labels the tool as a read operation ('Read') and identifies the data source ('Mirror Node'). It implies no side effects. Although it could mention specifics like behavior on invalid account IDs, the core behavioral trait is sufficiently disclosed.
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 of 12 words. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description covers the essential purpose and data returned. However, it could briefly mention that the response includes both HBAR and token balances, which it does implicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add additional meaning beyond the parameter's existing description in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('an account's HBAR and token balances'), and the source ('from the Mirror Node'). It is specific and distinguishes from sibling tools like hedera_get_token_balances or hedera_get_account_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hedera_get_account_info or hedera_get_token_balances. The description lacks context for selection among many sibling tools.
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?
The description transparently states the tool builds an unsigned transaction and requires admin key signing. This clarifies that execution is separate and the tool is not directly mutative. No annotations exist, so description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It efficiently conveys the core purpose and a critical condition.
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 3 parameters and no output schema, the description is adequate but incomplete. It explains purpose and a key condition but lacks explanation of the return value, how to execute the built transaction, and the role of 'payerAccountId'.
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?
With 0% schema coverage, the description should explain all parameters. It only mentions 'memo' and 'admin key' (the latter not a parameter), leaving 'payerAccountId' unexplained. 'contractId' is required but not detailed. Admin key is mentioned as a requirement but not as a parameter.
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: building an unsigned update to a contract's memo or admin key. It distinguishes from siblings like hedera_delete_contract or hedera_query_contract by specifying the editable fields and the signing requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the description: use when updating memo or admin key with admin key signing. However, no explicit guidance on when to use this versus other contract tools (e.g., hedera_execute_contract) or alternatives 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?
Describes that the tool 'Build (unsigned)' an account, indicating no immediate blockchain effect. Lacks return format details (probably a transaction object). With no annotations, the description carries full burden but does not fully disclose output.
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 clear sentence, 16 words, no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a create tool with full schema coverage, but lacks output format description and does not explain that the new account ID is generated automatically. Slightly incomplete given no 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 descriptions are complete (100% coverage). Description highlights publicKey and initialBalanceHbar but omits memo, payerAccountId, maxAutomaticTokenAssociations. Baseline 3 with marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Build' and resource 'new Hedera account' with specific inputs (public key, optional HBAR balance). Distinguishes from sibling tools like update/delete account.
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?
Usage is implied for creating new accounts; no explicit when-not or alternatives, but creation tools are self-explanatory. Could mention that the output is unsigned and needs subsequent signing.
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?
The description indicates it reads from the Mirror Node, implying a read-only operation. No additional behavioral details like rate limits or data freshness are provided, which would be useful but not critical for a simple query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and key output examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description is the only source of return information. It mentions only two fields, which may be incomplete for an agent relying on the description to understand the full response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by giving examples of output data (total staked, reward rate), but no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads network-wide staking info, using the verb 'Read' and specifying the resource 'network-wide staking info'. It distinguishes from siblings like account or token operations, as no other tool provides staking information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. However, the purpose is clear, and there is no alternative staking tool among siblings, so usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates a read-only operation via the verb 'Read' and lists returned data (signatures, executed status). However, it does not disclose error handling, required permissions, or format of the scheduleId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the verb 'Read', and contains no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately covers purpose and return data. Could be improved by mentioning that the schedule object includes fields like creatorAccountId, but the listed items (signatures, executed status) are sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter scheduleId has no description in the schema (0% coverage). The tool description does not explain the expected format of scheduleId (e.g., a string like '0.0.12345'), leaving agents to guess the correct input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'scheduled-transaction info' with specific details 'signatures, executed status' from the Mirror Node. It distinguishes from sibling schedule tools (create, sign, delete).
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 that this tool reads schedule info, but does not explicitly state when to use it versus alternatives like hedera_get_transaction. However, the name and description are sufficient for an agent to infer appropriate usage.
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?
Without annotations, the description carries the full burden. It reveals that the tool builds an unsigned transaction (not a direct update) and requires the admin key to sign. This is crucial behavioral context. However, it does not mention any side effects, idempotency, or output 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 sentence of 26 words, efficiently conveying action, updatable fields, and a key requirement. No redundant information, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description provides decent context (build unsigned, updatable fields, admin key). However, it omits explaining 'unsigned', that tokenId is required, the role of payerAccountId, and whether multiple fields can be updated simultaneously.
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?
With 0% schema description coverage, the description partially compensates by listing updatable fields (name, symbol, memo, treasury). It covers 5 of 6 parameters, missing payerAccountId. It adds meaning by explaining that these are fields to update, but lacks detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Build (unsigned) an update to a token', specifies the updatable fields (name, symbol, memo, or treasury), and mentions a key requirement (admin key). This distinguishes it from sibling tools that create, delete, or transfer tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for updating token properties but does not explicitly state when to use it versus alternatives like hedera_create_fungible_token or hedera_delete_token. No guidance on when not to use it or what prerequisites are needed beyond the admin key.
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 exist, so the description carries the burden. It indicates a read operation ('Read') but does not disclose additional traits like rate limits, data freshness, or response size. For a simple tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, perfectly concise sentence that wastes no words. Structure is optimal for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core action and resource, suitable for a simple read-only tool with no parameters and no output schema. It omits return format details, but the context is sufficient for an agent to invoke 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?
There are no parameters, and schema coverage is 100%. Per the rubric, 0 parameters yields a baseline of 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the network fee schedule, a specific verb-resource combination that distinguishes it from sibling tools like hedera_get_network_stake or hedera_get_network_supply.
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?
No explicit usage guidance is provided. Since the tool takes no parameters and is a read operation, usage is implied but not explicitly contextualized against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It indicates a read operation from the Mirror Node, which implies non-destructive behavior. However, it lacks details on idempotency, rate limits, or error conditions. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly states the tool's function. No unnecessary words, front-loaded, and concise.
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 parameterless, read-only tool with no output schema, the description is complete enough: it specifies the data returned (total/circulating supply) and the source (Mirror Node). Could potentially mention that it returns current values, but not essential.
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?
No parameters exist, so the description does not need to add parameter semantics. The schema coverage is 100% vacuously. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads total and circulating HBAR supply from the Mirror Node. It uses a specific verb ('Read') and resource ('HBAR supply'), and is distinct from siblings like hedera_get_network_stake.
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?
No explicit guidance on when to use this tool versus alternatives, but the simple read-only nature and unique purpose make the usage context clear. Implied usage is sufficient for this straightforward case.
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?
The description explains that the call is keyless, uses Mirror Node, and costs no gas, which is helpful. It also outlines the two invocation modes. Without annotations, this adds meaningful behavioral context beyond the schema, though it does not describe error handling or output 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 two sentences with no filler. It front-loads the core purpose and then lists the two input modes efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain the return value format (e.g., decoded result or raw hex). It adequately covers the input modes but lacks information about what the agent can expect after a successful call, leaving a gap for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping abi, functionName, args as one method ('auto encode/decode') and dataHex as fallback, clarifying the interplay between parameters beyond their individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a contract view/pure function via Mirror Node eth_call, distinguishing it from state-changing contract tools like hedera_execute_contract. The verb 'Read' and specification of 'view/pure function' make 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 two clear usage patterns: using abi+functionName+args for auto encode/decode, or raw dataHex. It implies read-only usage via 'view/pure function' and 'keyless, no gas', but does not explicitly exclude state-changing calls or compare to siblings like hedera_execute_contract.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ExpertVagabond/hedera-mcp'

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