Hedera Toolbox

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=true), the description adds valuable behavioral context: pricing model ('FREE'), scope (covers all 20 tools), currency units (HBAR/USD), and onboarding prerequisites. It clarifies what informational data is returned without contradicting the read-only safety annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is efficient (two sentences) but structurally fragmented—the first 'sentence' is actually a noun phrase list ('Platform wallet, live pricing...'). The word 'FREE' adds minimal technical value. However, every sentence does earn its place by conveying pricing, balance, or onboarding instructions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description adequately indicates return values (balance, pricing, wallet info) but does not describe their structure or format. Given the tool's simplicity (1 optional param) and clear differentiation from 20+ operational siblings, this is sufficient but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage (baseline 3), the description adds crucial semantic context: it explains that 'your Hedera account ID becomes your API key,' clarifying the relationship between the parameter and the authentication model. This helps the agent understand why an account ID might be passed as an API key.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (platform wallet, balance, pricing) and distinguishes from operational siblings (contract, token, etc. tools). While the opening 'Platform wallet...' is slightly fragmented, the text quickly clarifies this provides account information and pricing data specific to this platform.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Excellent explicit guidance: 'Call first to onboard' establishes mandatory sequencing. It further explains the onboarding workflow (send HBAR, account ID becomes API key), which is critical context for an optional-parameter tool that requires pre-funding.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

While annotations indicate this is a destructive write operation (destructiveHint=true), the description adds valuable behavioral context not present in structured fields: the cost ('FREE') and the dependency relationship (must execute before paid tools). It could further clarify the nature of the 'destructive' commitment (e.g., legal acceptance).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely efficient at three sentences. Each sentence delivers distinct, critical information: purpose ('Accept Terms of Service'), workflow constraint ('Required before any paid tool executes'), and cost classification ('FREE'). Zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simple 3-parameter structure with complete schema documentation and clear annotations, the description provides sufficient workflow context (cost and prerequisites). A minor gap is the lack of return value description, though no output schema exists to mandate this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the structured documentation already fully defines the parameters (api_key format, confirmed boolean constraint, terms_version source). The description adds no additional parameter-specific semantics, meeting the baseline expectation for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Accept') with a clear resource ('Terms of Service'). It effectively distinguishes this tool from its siblings by stating it is 'FREE' and 'Required before any paid tool executes,' clearly positioning it as a prerequisite distinct from the paid utility tools in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states the prerequisite condition ('Required before any paid tool executes'), providing clear guidance on when to invoke the tool. However, it could strengthen this by explicitly mentioning the workflow dependency on 'get_terms' to retrieve the version string, though this is implied by the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds critical cost information ('1.5 HBAR') not present in annotations. Enumerates specific analysis dimensions (risk, classification, gas) beyond generic 'analysis'. Aligns with readOnlyHint=true by using 'analysis' terminology; no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single efficient sentence front-loaded with key information. Every element serves purpose: resource type, analysis dimensions, and cost. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately complete for a 2-parameter read-only tool. Specifies analysis scope and cost. No output schema exists, so description appropriately hints at return value categories (activity, risk, classification) without requiring full specification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage with clear examples (e.g., '0.0.123456' for contract_id). Description adds no parameter details, but with full schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ('contract deep analysis') and clearly distinguishes from siblings 'contract_call' and 'contract_read' by emphasizing comprehensive analytics (activity, caller distribution, gas, risk, classification) rather than simple execution or state reading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides implicit guidance through 'deep analysis' label and enumerated dimensions, suggesting use for comprehensive risk/activity assessment vs simple interaction. However, lacks explicit 'when to use' guidance or named alternatives for simpler queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds crucial cost information ('1.0 HBAR') not present in annotations or schema. Reinforces non-destructive nature consistent with annotations (readOnlyHint: true). Does not contradict annotations and supplements them with economic context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely efficient three-sentence structure front-loaded with critical constraints: operation type, execution mode, and cost. Zero redundancy; every token provides distinct semantic value beyond the structured fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Sufficiently complete for a contract query tool: covers cost, safety profile (via annotations), and input parameters. Absence of output schema limits completeness, but 'return_types' parameter acknowledges dynamic return values. Minor gap regarding rate limits or error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing detailed documentation for all 6 parameters including 'abi_hint' and 'return_types'. Description adds no parameter-specific guidance, but baseline 3 is appropriate given comprehensive schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific action ('Read-only call') and resource ('Hedera contract function'). Clearly distinguishes write operations via 'No tx submitted', though lacks explicit differentiation from sibling tool 'contract_read' which may cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage context through 'Read-only' and 'No tx submitted', suggesting use when mutation is not desired. However, fails to explicitly contrast with 'contract_read' or state prerequisites for selecting this over sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds valuable behavioral context beyond annotations: discloses specific data returned (state info, bytecode, storage, activity), confirms no transaction execution occurs (aligning with readOnlyHint), and provides cost information (0.2 HBAR) not present in structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely compact with zero waste—every token conveys distinct operational value (resource, data types, behavioral guarantee, cost). Minor deduction for telegraphic colon-separated list style which slightly reduces readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Compensates well for missing output schema by enumerating returned data categories (info, bytecode, storage, activity). Cost and read-only nature are disclosed. Could benefit from mentioning rate limit implications of the API key requirement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema adequately documents both parameters. The description implies 'contract_id' is required by mentioning contract-specific data, but adds no semantic detail beyond the property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specifies retrieving Hedera contract state with concrete attributes (bytecode size, storage, recent activity). The phrase 'No tx executed' effectively signals read-only semantics, distinguishing it from the sibling 'contract_call' tool, though it doesn't explicitly name the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage boundaries through 'No tx executed' (don't use for execution) and mentions cost ('0.2 HBAR'), but lacks explicit guidance like 'Use contract_call instead to execute transactions' or prerequisites for the API key.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about what gets returned ('items posted by Scout, Narrator, or other agents') and the free nature of the call, but doesn't provide details about return format, pagination, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with three sentences that each serve a distinct purpose: stating the action, specifying what's returned, and providing access restrictions. There's no wasted verbiage and it's front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with good annotations and a simple single-parameter schema, the description provides adequate context about what's returned and access restrictions. The main gap is the lack of output schema, but the description compensates somewhat by specifying the source of items.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Read unresolved flagged items'), resource ('from the Fixatum agent inbox'), and scope ('posted by Scout, Narrator, or other agents requiring Midas attention'). It distinguishes itself from sibling tools like 'fixatum_fleet_status' by focusing on inbox items rather than general fleet status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('Read unresolved flagged items... requiring Midas attention') and includes clear exclusions ('Only callable by Midas (0.0.10435510)'). It also implies when not to use it by specifying the exact account requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable behavioral context beyond annotations: it specifies the return format ('latest report from each agent plus unresolved inbox item count'), cost ('Free'), and access control ('Only callable by Midas'). This enhances transparency without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by additional context in subsequent sentences. Every sentence adds value: the first defines the action, the second specifies returns, and the third covers cost and access. There's no wasted text, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (read-only operation with one parameter), the description is mostly complete. It covers purpose, returns, cost, and access. However, without an output schema, it could benefit from more detail on the return structure (e.g., format of 'latest report'). The annotations provide safety context, but the description compensates well overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'api_key' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, such as format details or usage examples. Baseline 3 is appropriate when the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Read all agent statuses and inbox count'), identifies the resource ('Fixatum agent communication layer'), and distinguishes from siblings by specifying what it returns ('latest report from each agent plus unresolved inbox item count'). It differentiates from fixatum_status and fixatum_fleet_inbox by focusing on fleet-wide status with inbox counts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('Read all agent statuses and inbox count') and includes an explicit access restriction ('Only callable by Midas'). However, it doesn't explicitly state when NOT to use it or name alternatives like fixatum_status or fixatum_fleet_inbox for more specific needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false (write operation), but the description adds critical behavioral context: the 100 HBAR cost, the permanence of the DID, the specific Ed25519 key requirement (distinct from Hedera ECDSA keys), and the dual-mode behavior (free prerequisite check vs paid registration). It discloses where data is anchored (Hedera HCS) without contradicting the non-destructive annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with zero waste: purpose statement first, followed by cost, technical requirements, and usage pattern. Every sentence delivers distinct value (purpose, cost, key constraints, prerequisite mode). No redundancy with schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of blockchain identity registration and lack of output schema, the description adequately covers the value proposition (DID, KYA score), cost model, cryptographic prerequisites, and operational modes. It could improve by hinting at error conditions or return value structure, but it successfully communicates the essential contract for a financial/mutation operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds crucial semantic context beyond the schema: it clarifies that hedera_account_id 'becomes part of your DID' and provides critical usage instructions for ed25519_public_key ('Omit to get prerequisites...' and 'NOT your Hedera ECDSA key'). This behavioral guidance for optional parameter omission is essential and not captured in schema structure alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool 'Register[s] this agent with Fixatum to get a permanent W3C-compliant DID... anchored to Hedera HCS and a live KYA trust score.' It uses a specific verb (Register), identifies the exact resource (Fixatum DID/KYA), and distinguishes from siblings like fixatum_score or fixatum_status by emphasizing the creation/anchoring action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear prerequisite guidance (dedicated Ed25519 key pair, NOT Hedera account key) and explicitly differentiates usage modes: 'Call with hedera_account_id only to get full prerequisites and key generation instructions' vs the full registration. It lacks explicit comparison to sibling alternatives (e.g., 'use fixatum_status to check existing registration'), but the cost warning (100 HBAR) and prerequisite pattern provide strong contextual guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations confirm read-only/non-destructive status. The description adds valuable behavioral context: cost ('Free'), return value structure (0-100 score, A-F grade, component breakdown), and acceptable input formats (Hedera account ID vs did:hedera DID). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, zero waste: (1) core purpose and scope constraint, (2) return value details, (3) cost, (4) input format. Front-loaded with the action verb and efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, the description appropriately details the expected return values (score, grade, breakdown). It also covers the 'registered agent' constraint and input requirements, making it complete for a simple 2-parameter read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, establishing a baseline of 3. The description reinforces the parameter semantics by specifying input formats ('Pass a Hedera account ID or full did:hedera DID'), but does not add substantial meaning beyond what the schema property descriptions already provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Query' with resource 'Fixatum KYA trust score' and clarifies the target is 'any registered agent'. However, it does not explicitly distinguish from siblings fixatum_register or fixatum_status, though the functional difference is inferable from the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for any registered agent' implies a prerequisite (registration required), suggesting the agent must use fixatum_register first. However, this is implicit guidance rather than explicit when-to-use/when-not-to-use instructions or explicit sibling references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

While annotations confirm read-only/non-destructive behavior, the description adds valuable operational context: it discloses that the tool is 'Free' (cost transparency) and details the specific return payload ('DID if registered, live score, and whether provenance is actively building') despite the absence of an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences efficiently deliver: (1) core function, (2) return values and cost, and (3) usage sequencing. Zero redundancy; every clause earns its place. Front-loaded with the action verb.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter read operation, the description adequately compensates for the missing output schema by detailing return contents (DID, score, provenance status). It covers cost, prerequisites (none beyond params), and workflow context. Minor gap: could specify behavior when account is not registered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the parameters are fully documented in the structured schema. The description references the target account ('for a Hedera account') but does not add semantic meaning beyond what the schema already provides for 'hedera_account_id' or 'api_key'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Check') and clear resource ('Fixatum registration status'), explicitly targeting 'a Hedera account.' It effectively distinguishes from sibling tool 'fixatum_register' by positioning this as the pre-registration status check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit workflow guidance: 'Use before fixatum_register to check if already registered.' This clearly defines when to invoke this tool versus its sibling alternative, preventing redundant registration attempts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint), the description adds crucial behavioral context: cost model ('FREE') and return format ('Machine-readable'). It does not contradict annotations. Could mention cache behavior or rate limits for a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short phrases, zero redundancy. Front-loaded with what it returns, followed by economic constraint (FREE) and workflow instruction. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool without output schema, the description is complete: it explains what is returned (machine-readable ToS), when to use it (before paid tools), cost (FREE), and the next step (confirm_terms). No gaps given tool simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters present, which per rules establishes a baseline of 4. The description correctly implies no configuration is needed by focusing entirely on workflow and return type rather than parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides 'Machine-readable Terms of Service' using a specific resource+format, and distinguishes itself from siblings by identifying as 'FREE' (contrasting with paid tools) and linking to the confirm_terms workflow step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit temporal guidance 'Call before any paid tool' and names the exact sibling tool to use next ('then confirm_terms'), creating a clear two-step workflow that differentiates this tool from confirm_terms.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond these: it specifies exactly what analysis is performed (sentiment, participation, concentration, prediction) and discloses the cost (1.0 HBAR), which is critical for agent decision-making.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single line with zero redundancy. The colon-separated list efficiently communicates analysis dimensions. The cost '1.0 HBAR' is front-loaded at the end, though slightly abrupt. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter read-only tool with no output schema, the description adequately covers functionality by listing analysis dimensions and cost. However, it lacks description of return format or data structure, which would be helpful given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific guidance (e.g., it doesn't clarify the relationship between required proposal_id and optional topic_id), but meets the baseline expectation since the schema fully documents parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool performs 'Governance proposal analysis' with specific dimensions: voter sentiment, participation, concentration, and outcome prediction. However, it does not explicitly differentiate from the sibling tool 'governance_monitor' (analysis vs. monitoring), preventing a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions '1.0 HBAR' implying a cost constraint, but provides no guidance on when to use this tool versus alternatives like 'governance_monitor', nor any prerequisites or conditions for invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the annotations: it discloses the cost ('0.2 HBAR') and specifies what data structures are returned (proposals, deadlines, tallies). This compensates for the lack of output schema. The read-only nature is consistent with the readOnlyHint annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely efficient structure: the first clause defines scope, the colon-delimited list specifies return data, and the final fragment notes cost. Every element earns its place with zero redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a read-only monitoring tool: it describes return values (compensating for missing output schema) and mentions cost. However, it omits rate limiting, pagination behavior, and the relationship to the optional topic_id parameter's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage (all 3 parameters have descriptions), the description appropriately rests on the schema for parameter details. It implies the token_id parameter via 'Hedera token or DAO' but adds no additional syntax, validation rules, or format guidance beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (Hedera token/DAO governance proposals) and specific data returned (open proposals, deadlines, vote tallies). However, it lacks explicit differentiation from the sibling 'governance_analyze' tool, leaving ambiguity about monitoring vs. analysis use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to select this tool over 'governance_analyze' or 'token_monitor'. There are no stated prerequisites, conditions, or explicit 'when not to use' instructions despite having several related sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds 'chronological' which implies result ordering, but provides no details on pagination behavior, rate limits, error handling (e.g., entity not found), or response structure. The API key requirement is documented only in 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with key information, but the fragment '2.0 HBAR' appears to be noise or metadata (possibly pricing) that wastes space without clarifying functionality. Two sentences where one would suffice if the cryptic suffix were removed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks explanation of what the audit trail contains, how records are structured, or what the return payload looks like. Given there is no output schema and four input parameters, the description should provide more context about the returned data format and volume expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline applies. The description does not elaborate on parameter semantics, but the schema comprehensively documents the four parameters including defaults (limit) and optional behavior (topic_id).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (chronological audit trail) and source (Hedera HCS) but uses a noun phrase rather than an action verb (e.g., 'Retrieves'). It fails to differentiate from siblings like hcs_query or hcs_verify_record. The trailing '2.0 HBAR' is cryptic and adds confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives like hcs_query, hcs_monitor, or hcs_verify_record. No mention of prerequisites or typical workflows despite being part of a large suite of HCS tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true (safe read). Description adds significant behavioral context beyond annotations: specific return fields (message count, creation time, memo), transaction cost (0.1 HBAR), and default scope. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Exceptionally concise with three discrete information units separated by periods. Front-loads the core purpose (HCS topic status) and efficiently appends metadata (defaults, cost). Zero redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter read-only tool with complete schema coverage and no output schema, the description adequately compensates by listing return fields and cost. Missing only minor details like pagination or rate limits, which is acceptable given the simplicity of a status check operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, establishing baseline 3. Description mentions the default topic behavior which overlaps with schema, and adds the cost information (0.1 HBAR) not present in schema. Does not elaborate on parameter syntax or formats beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly identifies the resource (HCS topic) and specific data returned (message count, creation time, memo). The colon structure telegraphically implies a retrieval/monitoring action. Distinguishes from sibling 'hcs_write_record' by being read-focused, though could explicitly verb 'Retrieves' or 'Gets' for perfection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete usage constraints: default behavior (platform topic) and cost (0.1 HBAR). However, lacks explicit guidance on when to use this versus siblings like 'hcs_query', 'hcs_audit_trail', or 'hcs_verify_record' which also interact with HCS topics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations confirming read-only safety, the description adds crucial behavioral details: the return format ('ranked messages and summary') and cost ('0.1 HBAR'), which are essential for agent decision-making.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences efficiently pack purpose, return values, and cost with zero waste. Information is front-loaded and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema exists, the description adequately discloses return values ('ranked messages and summary') and operational cost. It covers the essential behavioral context for a read-only query tool, though rate limits or error conditions could strengthen it further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the structured fields already document parameters fully. The description provides semantic context that aligns with the schema ('Natural language query' matching the query parameter description) but doesn't add syntactic guidance or format details beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb ('query'), resource ('HCS topic'), and distinguishes it from siblings like hcs_write_record or hcs_monitor by specifying 'Natural language query' as the interaction pattern.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

While 'Natural language query' implies when to use it (for questions vs. writes/monitoring), there are no explicit when-not-to-use guidelines or named alternatives among the many sibling HCS tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Crucially discloses the cost model ('1.0 HBAR') which is absent from annotations and schema. Annotations already establish read-only safety (readOnlyHint: true), so the description's value lies in adding the pricing context and elaborating the analytical scope beyond the schema enums.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely compact with zero filler. Front-loads the core purpose immediately. The cost disclosure at the end is efficient but could be slightly clearer with explicit labeling (e.g., 'Cost: 1.0 HBAR').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for the tool's moderate complexity (4 parameters) given strong schema coverage and safety annotations. However, lacks description of return values (no output schema exists to compensate) and omits usage context that would help an agent choose between the numerous sibling analysis tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, establishing a baseline of 3. The description adds semantic mapping by expanding enum values (anomaly_detection, trend_analysis, etc.) into descriptive phrases (anomaly detection, trends, entity extraction, risk), helping agents understand the analysis_type options conceptually.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (HCS topic) and specific verb/analysis types (anomaly detection, trends, entity extraction, risk). The term 'Deep' distinguishes it from sibling query/monitor tools, though explicit differentiation from hcs_query or hcs_monitor is absent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to select this tool versus siblings like hcs_query, hcs_monitor, or contract_analyze. The description lacks explicit prerequisites, success criteria, or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations establish read-only/non-destructive safety. Description adds critical behavioral context: the specific tamper-verification functionality and the 1.0 HBAR cost associated with the Hedera network call, which annotations do not cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. Front-loaded with action verb. Cost information is appended without clutter. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Well-covered via 100% schema descriptions, readOnly annotations, and cost disclosure. Minor gap: does not describe verification result format, though this is acceptable given no output schema is defined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for all 3 parameters (api_key, topic_id, record_id). Description carries baseline score 3 as it does not add parameter semantics beyond the schema, but schema is fully self-documenting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear specific verb (Verify) and resource (compliance record on Hedera HCS) with unique scope (tamper detection). Distinguishes implicitly from sibling hcs_write_record and hcs_query by specifying integrity verification, though explicit sibling comparison is absent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides cost constraint (1.0 HBAR) which informs usage decisions, but lacks explicit when-to-use guidance versus hcs_audit_trail or hcs_query for record retrieval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

While annotations correctly flag this as destructive and non-read-only, the description adds critical behavioral context: it discloses the return values ('Returns record ID and tx proof') and the explicit cost ('5.0 HBAR'). This cost information is vital for blockchain tools and not captured in annotations. It could be improved by mentioning confirmation times or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of three efficient clauses with zero waste: the action clause ('Write tamper-evident compliance record'), the return value clause ('Returns record ID and tx proof'), and the cost clause ('5.0 HBAR'). Each sentence earns its place and is appropriately front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a destructive blockchain operation with no output schema, the description adequately covers the essential missing pieces: the cost (5.0 HBAR) and the return values (record ID and transaction proof). It could be improved by mentioning error handling, confirmation delays, or the irreversible nature of blockchain writes, but it is sufficiently complete for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the structured fields already document each parameter's purpose (e.g., 'The compliance data to record'). The description provides baseline value by characterizing the data as 'tamper-evident' but does not add syntax details, validation rules, or format requirements beyond what the schema already captures.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: 'Write tamper-evident compliance record to Hedera HCS.' It uses a specific verb (write), identifies the resource (compliance record), and specifies the target system (Hedera HCS), clearly distinguishing it from sibling read/analyze tools like hcs_query, hcs_verify_record, and hcs_monitor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage considerations through the cost disclosure ('5.0 HBAR'), signaling that this is a paid blockchain transaction requiring economic consideration. However, it lacks explicit guidance on when to use this tool versus similar siblings like hcs_audit_trail or hcs_verify_record, and provides no 'when-not-to-use' exclusions or prerequisites beyond the implicit cost.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations establish read-only safety. The description adds critical behavioral context: the cost ('1.0 HBAR') and specific analysis scope ('tx patterns, counterparty risk') that are absent from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact fragments deliver purpose, analysis scope, and pricing without redundancy. The trailing '1.0 HBAR' is telegraphic but efficiently conveys cost. Front-loaded structure puts the core action first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Includes necessary cost context for a paid screening operation, but lacks output description (no output schema exists). Given the analytical nature of the tool, some indication of return value structure (risk scores, flags) would be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage with clear examples for account_id and api_key purpose. Description mentions 'Hedera account' which aligns with account_id but does not augment semantics beyond what the schema already provides; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description provides specific verb-resource pair ('Sanctions and risk screening for a Hedera account') and distinguishes scope with 'tx patterns, counterparty risk'. It differentiates from identity_verify_kyc by emphasizing sanctions specifically, though it 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to select this tool versus identity_verify_kyc or identity_resolve. The agent must infer usage solely from the name and the term 'sanctions' without explicit 'when-to-use' criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, confirming safety. Description adds critical behavioral context not in structured data: the query costs '0.2 HBAR' and returns specific fields (age, tokens, tx history). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence. Front-loaded with action and resource, followed by return value specification, ending with cost. Every element earns its place; zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but description partially compensates by listing return fields (age, tokens, tx history). Cost disclosure addresses economic behavior. Safety annotations cover mutation risks. Could improve by noting rate limits or error conditions, but adequate for a lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both 'account_id' and 'api_key' fully documented. Description does not add parameter semantics beyond what the schema provides (e.g., no format guidance for EVM addresses beyond schema examples). Baseline 3 appropriate given complete schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear specific verb ('Resolve'), resource ('Hedera account ID or EVM address'), and output ('on-chain profile: age, tokens, tx history'). Distinguishes from identity_check_sanctions and identity_verify_kyc by focusing on profile resolution rather than sanctions/KYC. However, lacks explicit differentiation from sibling 'account_info' which may overlap in functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use guidance or comparison to alternatives. While the '0.2 HBAR' cost implies a paid lookup service, it does not state prerequisites (e.g., valid API key) or when to prefer this over 'account_info' or other identity tools. Missing explicit exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, non-destructive behavior. The description adds the cost (0.5 HBAR), which is critical behavioral context for a paid API/blockchain operation. However, it lacks details on return format, pagination, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise with two information-dense fragments. The cost and purpose are front-loaded with zero redundancy. Minor deduction for grammatical incompleteness ('KYC status of...' rather than a complete sentence).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Sufficient for a simple read operation with good schema coverage. Includes pricing (0.5 HBAR) which is essential for this domain. However, lacks description of return values, error states, or details on the KYC verification result structure despite having 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the structured fields adequately document parameters. The description adds minimal parameter-specific context beyond the schema, though 'one or more tokens' hints at the optional token_id behavior (checking all vs. specific token).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the subject (KYC status) and scope (Hedera account, tokens) but lacks an explicit verb (e.g., 'Retrieves' or 'Checks'). It distinguishes from siblings like identity_check_sanctions by specifying 'KYC' versus 'sanctions', but the fragment structure limits clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 siblings (identity_check_sanctions, identity_resolve) or prerequisites. The cost indicator (0.5 HBAR) hints at resource requirements but does not constitute usage guidelines.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses cost ('0.6 HBAR') which is critical behavioral context not found in annotations. Lists specific metrics included in the analysis (velocity, liquidity, etc.), effectively describing the return profile without an output schema. Consistent with readOnlyHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely compact (one sentence fragment + cost note). Efficiently front-loaded with action. However, '0.6 HBAR' lacks context (is this a fee, minimum balance, or example?), creating mild ambiguity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple 2-parameter read-only tool. Mentions the analysis scope and cost, covering essential behavioral gaps left by missing output schema. Could clarify authentication requirements or rate limits associated with the API key.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage (both parameters fully documented), establishing baseline 3. Description adds no parameter-specific semantics (e.g., token_id format nuances, api_key security handling), but none needed given complete schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific action ('deep analysis') and resource ('Hedera token') clearly. Lists specific analysis dimensions (holder distribution, velocity, liquidity, risk score) which implicitly distinguishes from sibling 'token_price' (surface-level) and 'token_monitor' (ongoing tracking), though it doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no guidance on when to use this versus sibling tools like 'token_monitor' or 'token_price'. No mention of prerequisites (e.g., API key procurement) or when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, confirming this is a safe read operation. The description adds behavioral context by specifying it tracks 'whale movements' and 'unusual transfer patterns' (anomaly detection), which is useful. However, it omits return format details, pagination behavior, rate limits, or thresholds defining 'whale' status. The '0.2 HBAR' remains cryptic—potentially indicating cost or filter threshold—but is insufficiently explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

While brief, the description suffers from opacity. The '0.2 HBAR' fragment appears tacked on without context, rendering it noise rather than useful data. It is front-loaded with the core concept, but the second sentence/fragment fails to earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, the description should explain what data structure or fields are returned (e.g., transaction list, timestamps, sender/receiver). It provides no such detail. Combined with no usage guidelines and minimal behavioral disclosure, the description is incomplete for a 3-parameter monitoring tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the structured fields already fully document the parameters (token_id format, api_key purpose, and limit constraints). The description adds no semantic clarifications beyond the schema, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the domain (Hedera token) and scope (whale movements, unusual transfer patterns), but uses a noun phrase without a clear action verb (retrieve, monitor, alert?). It fails to distinguish from sibling tools like 'token_analyze' or 'token_price'. The trailing '0.2 HBAR' fragment introduces confusion—unclear if cost, example, or threshold.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to select this tool versus siblings like 'token_analyze' (likely for metadata) or 'hcs_monitor' (likely for Hedera Consensus Service). No mention of prerequisites despite requiring a specific 'HederaIntel API key'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The '0.1 HBAR' likely indicates query cost/rate limiting, adding valuable behavioral context beyond the annotations. With readOnlyHint=true confirming safe read operations, the description adds the cost dimension that annotations don't cover. No contradictions with the safety annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise two-sentence structure with zero filler. Main deliverables front-loaded. Minor deduction for the unexplained '0.1 HBAR' (cost notation) which could confuse users about whether it refers to the token's price or the query cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Appropriate for a simple lookup tool with two parameters. Describes the three data points returned (price, market cap, volume) and implies cost. Given readOnly annotations and simple input schema, no additional complexity disclosure is required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage (token_id and api_key both documented), the description doesn't need to repeat parameter details. It neither adds validation rules (e.g., token ID format) nor provides usage examples, meriting the baseline score of 3 for fully documented schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (Hedera token) and specific data retrieved (price, market cap, 24h volume). It implicitly distinguishes from siblings like token_analyze (general analysis) and token_monitor (ongoing monitoring) by focusing specifically on pricing metrics. The '0.1 HBAR' fragment is cryptic but doesn't obscure the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives like token_analyze or token_monitor. No mention of prerequisites (like needing an API key) or rate limiting beyond the ambiguous '0.1 HBAR' cost indicator.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.