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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates key behavioral traits: that it's a query (not a mutation), that it's free (no transaction fee), that it uses Mirror Node infrastructure, and what format the HBAR balance returns in (ℏ format). However, it doesn't mention potential limitations like rate limits 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?

The description is efficiently structured with clear sections (purpose, returns, cost, usage) in just four sentences. Every sentence earns its place by providing distinct, valuable information without 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?

For a single-parameter query tool with no output schema, the description provides excellent context about what the tool does, when to use it, cost implications, and return format. The only minor gap is the lack of output structure details, but given the tool's simplicity and clear return description, this is acceptable.

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 'accountId' parameter with its format. The description doesn't add any additional parameter semantics beyond what's in the schema, making the baseline score of 3 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 clearly states the specific action ('Query'), resource ('HBAR and token balances'), and target ('any Hedera account'). It distinguishes itself from sibling tools like 'account_info' by focusing specifically on balance queries rather than general account information.

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 'USE FOR' section explicitly lists three specific use cases: 'Checking account balances, monitoring funds, verifying token holdings.' This provides clear guidance on when to use this tool versus alternatives like 'account_info' which might provide broader account details.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it creates a new account (mutation), funds it with HBAR (cost implication), and returns specific data (Account ID, keys, transaction ID). It also mentions costs (network fee + initial balance) and a recommended minimum (1 HBAR), adding valuable context beyond basic functionality.

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

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

The description is well-structured with clear sections (CREATES, FUNDS, RETURNS, USE FOR, COSTS), each sentence adds value without redundancy, and it is front-loaded with the core purpose. It efficiently conveys necessary information in a compact format.

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 annotations and no output schema, the description does a good job covering key aspects: purpose, usage, behaviors, and costs. It explains what the tool does, when to use it, and what to expect (returns and costs). However, it lacks details on error handling or transaction confirmation, which could be relevant for a mutation tool, keeping it from a perfect score.

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 documents all parameters (initialBalance, memo, publicKey) with descriptions. The description adds some context by mentioning 'auto-generated ECDSA key pair (or use provided public key)' for the publicKey parameter, but this is minimal enhancement over the schema. Baseline 3 is appropriate as the schema does most of the work.

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 ('Create a new Hedera account') and resource ('account'), distinguishing it from sibling tools like account_balance or account_info. It provides concrete details about what gets created (account with key pair) and funded (HBAR balance), making the purpose unambiguous and distinct.

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

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

The 'USE FOR' section explicitly lists contexts (testing, development, production workflows), giving clear guidance on when to use this tool. However, it does not mention when NOT to use it or name specific alternatives among siblings (e.g., account_info for querying), which prevents a perfect score.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond basic functionality: it specifies what information is returned (balance, EVM address, etc.), notes it's a Mirror Node query (implying read-only, non-destructive), and explicitly states 'FREE: No transaction fee,' which is crucial for cost-awareness. However, it doesn't mention rate limits, authentication needs, or error handling, leaving some behavioral aspects uncovered.

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

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

The description is efficiently structured with clear sections (purpose, returns, cost, usage) in just four sentences. Each sentence earns its place by providing distinct value: the first states the core action, the second details returns, the third clarifies cost, and the fourth offers usage guidelines. It's front-loaded with the main purpose and avoids any redundant or vague phrasing.

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 (a read-only query with one parameter), no annotations, and no output schema, the description does well by covering key aspects: purpose, returns, cost, and usage. However, it lacks details on output format (e.g., JSON structure) and potential errors, which could be important for an AI agent to handle responses correctly, slightly reducing completeness.

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?

The input schema has 100% description coverage, with the single parameter 'accountId' well-documented in the schema itself ('Account ID (format: 0.0.xxxxx)'). The description adds no additional parameter semantics beyond what the schema provides, such as examples or edge cases, so it meets the baseline of 3 for high schema coverage without compensating value.

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 ('Get comprehensive Hedera account information') and resource ('Hedera account'), distinguishing it from siblings like 'account_balance' (which only returns balance) and 'account_create' (which creates accounts). The verb 'Get' is precise and the scope 'comprehensive' sets expectations appropriately.

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 provides usage guidance with 'USE FOR: Account inspection, EVM address lookup, key verification, expiration monitoring.' This gives clear scenarios when to use this tool versus alternatives like 'account_balance' for just balance or 'mirror_query_account' for similar queries, making it highly actionable for an AI agent.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining key behavioral traits: distinguishing between 'add' (reference only, no private key) and 'import' (with private key for transaction signing), and specifying that operations work on saved accounts with aliases. However, it doesn't mention potential side effects like data persistence, error conditions, or security implications of handling private keys.

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 well-structured with clear sections (OPERATIONS, USE THIS FOR) and uses bullet points for operations. Every sentence earns its place: the opening establishes purpose, operations are clearly listed with brief explanations, and the usage guideline is front-loaded. No wasted words or 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 no annotations and no output schema, the description does a good job covering the tool's functionality. It explains all operations, their purposes, and usage context. However, it doesn't describe what the tool returns (e.g., success confirmation, list output format, error messages), which would be helpful since there's no output schema. For a multi-operation tool with behavioral nuances, this is a minor gap.

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 baseline is 3. The description adds significant value by explaining the semantic differences between operations: 'add' vs 'import' clarifies when privateKey is needed, and 'update' specifies it's for nicknames. It also clarifies that alias is for 'quick reference' and operations apply to 'saved accounts.' This provides context beyond the schema's technical 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?

The description clearly states the tool's purpose: managing Hedera account address books for multi-account workflows. It specifies the exact operations (add, import, list, update, remove) and distinguishes this from sibling tools like account_create, account_info, or transfer_hbar by focusing on address book management rather than account creation, information retrieval, or transactions.

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 'USE THIS FOR: Managing multiple accounts, organizing workflows, quick account reference.' This provides clear guidance on when to use this tool versus alternatives. It differentiates from account management tools by focusing on address book organization rather than direct account operations.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what the tool creates (complete, runnable code) and lists supported languages and styles, which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what happens when generation fails.

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 well-structured with clear sections (CREATES, LANGUAGES, STYLES, USE FOR) and uses bullet-like formatting. Every sentence adds value, though the 'USE FOR' section could be more concise. The description is appropriately sized for a tool with 5 parameters and no 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?

For a code generation tool with 5 parameters and no output schema, the description provides good context about what it creates, languages, and styles. However, it lacks information about the output format (what exactly is returned), error conditions, or any limitations. With no annotations and no output schema, more behavioral context would be helpful.

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 documents all 5 parameters thoroughly. The description adds some context by listing languages and styles in a more readable format, but doesn't provide additional semantic meaning beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool 'generates context-aware Hedera SDK code from natural language' with specific details about what it creates (complete, runnable code with imports, error handling, best practices). It distinguishes itself from sibling tools like 'docs_get_example' or 'foundry_contract' by focusing on code generation rather than documentation retrieval or contract management.

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 'USE FOR' section explicitly lists three use cases: creating new implementations, generating boilerplate, and scaffolding projects. This provides clear context for when to use this tool. However, it doesn't specify when NOT to use it or mention alternatives like 'docs_get_example' for existing code examples.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond basic functionality: it mentions auto-detection of Hardhat or Foundry, support for constructor arguments and gas limits, auto-verification, and tracking deployment history with metadata. However, it lacks details on permissions, rate limits, error handling, or response format, which are important for a deployment tool.

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 well-structured and front-loaded with the core purpose, followed by bullet-like sections (AUTO-DETECTS, SUPPORTS, TRACKS, USE FOR) that efficiently convey key information without waste. Every sentence earns its place by adding distinct value.

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 a deployment tool with no annotations and no output schema, the description does a good job covering purpose, usage, and behavioral traits. However, it lacks details on return values or error cases, which would be helpful for completeness. It compensates somewhat with clear usage guidelines and transparency.

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 documents all 5 parameters thoroughly. The description adds minimal value beyond the schema: it implies framework auto-detection and verification features but doesn't provide additional syntax or format details. This meets the baseline of 3 when schema coverage is high.

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

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

The description clearly states the tool deploys smart contracts to Hedera with a unified interface, specifying the verb 'deploy' and resource 'smart contract'. It distinguishes from siblings like rpc_deploy_contract by emphasizing auto-detection of frameworks, constructor arguments, gas limits, and verification features, making it specific and differentiated.

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 'USE FOR: Production contract deployment, automated workflows, verified deployments,' providing clear context on when to use this tool. It distinguishes from alternatives like verify_contract by focusing on deployment with verification, and from rpc_deploy_contract by highlighting framework auto-detection and tracking features.

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?

No annotations are provided, so the description carries the full burden. It mentions filtering and export capabilities, but doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'view'), potential rate limits, authentication needs, or what the output looks like (e.g., pagination, error handling). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is well-structured with sections (FILTERS, EXPORTS, USE FOR) and uses bullet-like formatting for clarity. It's concise, with each sentence adding value, though it could be more front-loaded by starting with the core purpose. No wasted words, but minor improvements in flow are possible.

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 annotations, no output schema, and 4 parameters with 50% schema coverage, the description provides basic context but is incomplete. It covers what the tool does and some parameter semantics, but lacks details on behavioral aspects, output format, or error handling. For a tool with moderate complexity, this 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.

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

Schema description coverage is 50%, with parameters 'network' and 'exportFormat' having enums and 'contractName' and 'limit' having brief descriptions. The description adds value by listing filters (network, contract name, status) and export formats (JSON, CSV, Markdown), which clarifies the purpose of some parameters. However, it doesn't fully compensate for the coverage gap, as 'status' is mentioned but not in the schema, and details like default values or usage are sparse.

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's purpose: 'View deployment history with filtering and export.' It specifies the resource (deployment history) and actions (view, filter, export). However, it doesn't explicitly differentiate from sibling tools like 'deploy_contract' or 'verify_contract' which might also involve deployment operations, though the focus on history tracking is implied.

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 includes 'USE FOR: Tracking deployments, auditing, documentation,' which provides context on when to use this tool. However, it lacks explicit guidance on when not to use it or alternatives among siblings (e.g., 'deploy_contract' for new deployments vs. this for history). The guidance is implied but not comprehensive.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it uses RAG (Retrieval-Augmented Generation), handles various question types (conceptual, how-to, etc.), returns comprehensive answers with code examples and citations, and adjusts for expertise levels. However, it doesn't mention potential limitations like response time, accuracy constraints, or data freshness.

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 well-structured with clear sections (HANDLES, RETURNS, EXPERTISE, USE FOR) and front-loaded with the core purpose. However, the final sentence ('THIS IS YOUR PRIMARY TOOL...') is somewhat redundant with the USE FOR section, and the description could be slightly more concise by combining related points.

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 knowledge Q&A tool with no annotations and no output schema, the description provides good contextual completeness. It covers purpose, usage, capabilities, and return format. The main gap is the lack of output schema, but the description compensates by detailing what the tool returns (comprehensive answers with code examples and citations). It could be more complete by mentioning response format or potential errors.

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 documents all four parameters thoroughly. The description adds some context by mentioning 'expertise level' and 'code examples' in the RETURNS and EXPERTISE sections, but doesn't provide additional semantic meaning beyond what's in the schema descriptions. This meets the baseline of 3 when schema coverage is high.

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

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

The description clearly states the tool's purpose: 'Answer ANY knowledge question about Hedera using RAG.' It specifies the verb ('Answer'), resource ('knowledge question about Hedera'), and method ('using RAG'), distinguishing it from sibling tools like docs_search or error_explain that likely serve different functions.

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 explicit usage guidance: 'USE FOR: Learning Hedera concepts, getting implementation guidance, understanding best practices. THIS IS YOUR PRIMARY TOOL FOR HEDERA KNOWLEDGE QUESTIONS.' It clearly defines when to use this tool (for knowledge questions) versus alternatives like code_generate or account_balance, and lists specific question types it handles.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool returns ('Annotated code with explanations and source references') and what it searches, but lacks details on rate limits, authentication needs, error handling, or pagination behavior. It provides basic operational context but misses important 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.

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

The description is well-structured with clear sections (SEARCHES, RETURNS, LANGUAGES, USE FOR), front-loaded with the core purpose, and every sentence adds value without redundancy. It's appropriately sized for a tool with 4 parameters and clear differentiation needs.

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 (4 parameters, no output schema, no annotations), the description provides good context: clear purpose, usage guidelines, return format, and language support. However, it lacks details on behavioral aspects like error cases or performance characteristics that would be helpful for an agent.

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 50% (2 of 4 parameters have descriptions). The description adds value by listing supported languages (matching the 'language' enum) and implying the 'description' parameter's purpose through context, but doesn't explain 'complexity' or 'limit' beyond what the schema provides. It partially compensates for the coverage gap but not fully.

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's purpose with specific verbs ('Find working code examples') and resources ('Hedera functionality'), and distinguishes it from siblings like docs_ask or docs_search by focusing on code examples rather than general documentation. It explicitly lists what it searches for (SDK examples, tutorials, implementation patterns).

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 explicit usage guidance with a 'USE FOR' section that lists specific scenarios (getting implementation code, learning patterns, finding SDK usage), helping differentiate it from alternatives like code_generate or general documentation tools. It clearly indicates when 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.

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

With no annotations provided, the description carries full burden and does well by specifying what content is indexed, what the tool returns (ranked results with specific fields), and available filters. It doesn't mention rate limits, authentication requirements, or pagination behavior, but provides substantial operational context for a search tool.

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

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

Excellent structure with clear sections (INDEXED, RETURNS, FILTERS, USE FOR) that are front-loaded and information-dense. Every sentence earns its place by providing distinct, valuable information without repetition or fluff.

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 search tool with 4 parameters, 50% schema coverage, and no output schema, the description provides strong context about indexed content, return format, and use cases. It could benefit from mentioning the default limit value (mentioned in schema but not description) and result format details, but is largely complete for its complexity level.

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 50% (query and limit have descriptions, contentType and language don't). The description compensates by explaining the 'content type' filter options and 'language' filter purpose in the FILTERS section, adding meaningful context beyond the bare enum values 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 tool performs 'Semantic search across complete Hedera documentation' with specific scope (official docs, SDK references, tutorials, HIPs, service specs). It distinguishes from sibling tools like docs_ask and docs_get_example by focusing on comprehensive search rather than specific question-answering or example retrieval.

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 'USE FOR' section explicitly lists three specific use cases: 'Finding specific documentation, discovering relevant tutorials, locating API references.' This provides clear guidance on when this tool is appropriate versus other documentation-related tools like docs_ask or general-purpose 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?

No annotations are provided, so the description carries the full burden. It states the tool 'explains' and provides 'debugging guidance,' which implies it's a read-only informational tool. However, it doesn't disclose behavioral traits like response format, whether it queries a database or uses AI, rate limits, or authentication needs. The description adds basic context but lacks operational details.

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 well-structured with clear sections (purpose, USE FOR, EXAMPLES), front-loaded with the core purpose, and every sentence earns its place by providing specific guidance or examples without redundancy. It's appropriately sized for a tool with multiple use cases.

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 (4 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, usage guidelines, and examples, which helps an agent understand when and how to invoke it. However, without annotations or output schema, it could benefit from more behavioral context (e.g., response format), but the existing content is sufficient for basic use.

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 documents all four parameters well. The description doesn't add parameter-specific semantics beyond what's in the schema, but the 'EXAMPLES' section implicitly illustrates usage patterns (e.g., querying by error code or category). With high schema coverage, the baseline is 3, and the examples provide slight additional value.

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's purpose: 'Explain Hedera error codes and provide debugging guidance.' This is a specific verb ('explain') + resource ('Hedera error codes') combination that distinguishes it from all sibling tools, which focus on account management, contract deployment, token operations, etc., rather than error explanation.

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 'USE FOR' section explicitly lists three scenarios for when to use this tool: understanding cryptic error codes, getting step-by-step solutions, and finding related errors/security recommendations. This provides clear context and distinguishes it from alternatives like general documentation tools (docs_ask, docs_search) or debugging through other means.

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?

With no annotations provided, the description carries the full burden and adds significant behavioral context. It discloses that 'privateKey and rpcUrl are OPTIONAL - if not provided, automatically uses MCP operator account configuration', which is crucial for understanding authentication and configuration. It also hints at cost implications ('call: Call read-only function via cast (FREE)') and operational scope (e.g., local development with Anvil).

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 well-structured with clear sections (OPERATIONS, AUTO-RESOLUTION, USE FOR) and front-loaded key information. It's appropriately sized for a complex tool with many operations, though some sentences could be more concise (e.g., the OPERATIONS list is verbose but necessary).

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 high complexity (19 parameters, 7 operations), no annotations, and no output schema, the description does a good job of providing context. It covers purpose, usage, key behavioral traits (auto-resolution, free operations), and operational scope. However, it lacks details on error handling, response formats, or prerequisites (e.g., Foundry installation), leaving some gaps.

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 documents all 19 parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it mentions optional auto-resolution for 'privateKey' and 'rpcUrl' and loosely ties some parameters to operations (e.g., 'matchTest' for 'test'), but doesn't provide additional syntax or format details. Baseline 3 is appropriate given high 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?

The description clearly states the tool's purpose as 'Manage Foundry contract testing, deployment, and interaction' with a specific verb ('manage') and resource ('Foundry contract'), and it distinguishes from siblings like 'deploy_contract' and 'hardhat_contract' by specifying the Foundry framework context. The OPERATIONS list further clarifies the scope.

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 explicit context for when to use this tool ('USE FOR: Testing, deployment, gas analysis, and local development'), which helps differentiate it from general-purpose siblings like 'rpc_call' or 'deploy_contract'. However, it lacks explicit exclusions or direct alternatives (e.g., when to use 'hardhat_contract' instead).

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by listing all operations and their purposes, but doesn't disclose important behavioral traits like whether operations are read-only vs. destructive, permission requirements, rate limits, or error handling. The description adds operational context but lacks safety and performance information.

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 well-structured with clear sections (overview, operations list, usage context) and every sentence earns its place. It's appropriately sized for a multi-operation tool. Minor improvement could be made by front-loading the most critical information more prominently, but overall it's efficient and organized.

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 complexity (10 operations, 9 parameters) and absence of both annotations and output schema, the description provides good operational coverage but has significant gaps. It explains what each operation does but doesn't describe return values, error conditions, or behavioral constraints. For a multi-operation tool with no structured safety information, this is adequate but incomplete.

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 already documents all 9 parameters thoroughly. The description adds value by mapping operations to their required parameters (e.g., 'template for init', 'dependency for install/remove'), but doesn't provide additional semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose as 'Manage Foundry project lifecycle operations' and provides a comprehensive list of 10 specific operations with distinct verbs and resources. It effectively distinguishes this tool from siblings like 'foundry_contract' or 'hardhat_project' by focusing on project-level operations rather than contract-specific or alternative framework tasks.

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 'USE FOR' section explicitly states the contexts for using this tool: 'Project setup, dependencies, compilation, and gas optimization.' This provides clear guidance on when to use it. However, it doesn't specify when NOT to use it or name specific alternative tools for overlapping functionality, preventing a perfect score.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does provide some useful behavioral context: the AUTO-RESOLUTION section explains credential handling, and it distinguishes between 'call' (read-only, FREE) and 'execute' (state-changing). However, it doesn't address important behavioral aspects like error handling, rate limits, network requirements, or what happens during deployment failures.

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 well-structured with clear sections (OPERATIONS, AUTO-RESOLUTION, USE FOR) and uses bullet points effectively. It's appropriately sized for a multi-operation tool with 13 parameters. While efficient, the 'OPERATIONS' section could be slightly more concise by integrating the parenthetical clarifications into the main bullet points.

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 complexity (13 parameters, 5 operations, no annotations, no output schema), the description provides a reasonable foundation but has significant gaps. It explains what operations are available and some behavioral aspects, but doesn't address error cases, return formats, or prerequisites. For a tool with this many parameters and operations interacting with blockchain contracts, more comprehensive guidance would be helpful.

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 documents all 13 parameters thoroughly. The description adds minimal parameter semantics - it mentions that 'deploy_ignition' uses 'Hardhat Ignition (declarative)' and that 'call' is read-only while 'execute' is state-changing. These are helpful clarifications, but most parameter context remains in the schema. The baseline of 3 is appropriate given the 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?

The description clearly states the tool's purpose as 'Manage Hardhat contract deployment and interaction' and lists five specific operations, providing a comprehensive overview. However, it doesn't explicitly distinguish this tool from sibling tools like 'deploy_contract', 'verify_contract', or 'rpc_deploy_contract', which appear to have overlapping functionality in the same domain.

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 'USE FOR' section explicitly states when to use this tool: 'Contract deployment, verification, and interaction.' This provides clear context about appropriate use cases. However, it doesn't specify when NOT to use it or mention alternatives among the many sibling tools that appear related (like deploy_contract, verify_contract, rpc_deploy_contract, etc.).

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?

With no annotations provided, the description carries full burden for behavioral disclosure. While it lists operations, it doesn't explain critical behavioral aspects: which operations are read-only vs. mutating, what permissions are required, whether operations have side effects, or how errors are handled. For a complex tool with 13 parameters and no annotations, this represents a significant gap in behavioral transparency.

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

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

The description is well-structured with clear sections (OPERATIONS, USE FOR) and uses bullet points for readability. While comprehensive, it could be more concise - some operation descriptions could be streamlined, and the structure is effective but not perfectly front-loaded with the most critical information.

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 complex tool with 13 parameters, no annotations, and no output schema, the description provides adequate operational overview but lacks critical context. It doesn't explain return values, error conditions, or behavioral constraints. The description covers what the tool does but not how it behaves or what results to expect, leaving significant gaps given the tool's complexity.

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 documents all 13 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'force option' for compile and 'filtering' for test, but doesn't provide additional semantic context about parameter usage, dependencies, or constraints beyond what's in the schema 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?

The description clearly states the tool 'Manage[s] Hardhat project lifecycle operations' and lists 10 specific operations, providing a comprehensive overview of its functionality. However, it doesn't explicitly differentiate from sibling tools like 'hardhat_contract' or 'foundry_project' which might have overlapping functionality in the same domain.

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 'USE FOR' section provides general guidance ('Project setup, compilation, testing, and configuration management'), but doesn't specify when to choose this tool over alternatives like 'hardhat_contract' or 'foundry_project'. The guidance is helpful but lacks explicit comparison with sibling tools that handle similar blockchain development tasks.

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?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: 'auto-chunks if >1KB' for submit operation and 'FREE via Mirror Node' for query operation. It doesn't mention rate limits, authentication needs, or error behaviors, but provides useful operational context.

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

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

The description is perfectly structured with clear sections (OPERATIONS, USE THIS FOR), uses bullet points efficiently, and every sentence earns its place. No wasted words while maintaining complete clarity.

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 tool with 6 parameters, 100% schema coverage, but no annotations and no output schema, the description does well by explaining the two operations and their use cases. It could benefit from mentioning return formats or error handling, but provides sufficient context for agent decision-making.

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 baseline is 3. The description adds some value by clarifying that 'message' is 'for submit' and mentioning filtering for query, but doesn't provide significant additional semantics beyond what's already in the schema 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?

The description clearly states the tool performs HCS message operations, specifically 'submit' and 'query' with explicit verbs and resources. It distinguishes itself from sibling tools like 'hcs_topic' (likely for topic management) by focusing on message operations rather than topic operations.

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 explicit usage guidance with 'USE THIS FOR: Publishing messages, retrieving consensus-ordered data, auditable logs.' This clearly indicates when to use this tool versus alternatives like 'hcs_topic' for topic management or other data query 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?

With no annotations provided, the description carries full burden for behavioral disclosure. While it lists operations, it doesn't describe key behavioral aspects: whether operations are read-only or mutating (create/update clearly mutate), authentication requirements, rate limits, error conditions, or what happens during subscription. The description mentions 'real-time message streams' but doesn't explain how subscriptions work or their persistence.

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 well-structured with clear sections (OPERATIONS, USE THIS FOR) and uses bullet points efficiently. It's appropriately sized for a multi-operation tool. However, the first line 'Hedera Consensus Service (HCS) topic management.' is somewhat redundant with the tool name, and the description could be slightly more front-loaded with the most critical information.

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 complexity (7 parameters, 3 distinct operations, no output schema, no annotations), the description is moderately complete. It covers the operations and usage context but lacks important behavioral details needed for a mutation-heavy tool. Without annotations or output schema, the description should provide more about what happens after operations (e.g., what create returns, how subscriptions manifest).

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 documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'public or private topic' which relates to the submitKey parameter, and 'configurable keys' which relates to adminKey/submitKey. This provides some context but doesn't significantly enhance understanding beyond what the schema already provides.

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's purpose as 'Hedera Consensus Service (HCS) topic management' and lists three specific operations (create, update, subscribe). It distinguishes this tool from sibling 'hcs_message' by focusing on topic management rather than message handling. However, it doesn't explicitly differentiate from other consensus or management 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?

The 'USE THIS FOR' section provides clear context about when to use this tool: 'Creating consensus topics, configuring topic settings, real-time message streams.' This gives practical guidance. However, it doesn't specify when NOT to use it or mention alternatives among the many sibling tools (like when to use hcs_message vs this tool for message-related tasks).

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?

With no annotations provided, the description carries the full burden. It discloses the return values (version, tool count, optimization level) and mentions a parameter effect ('verbose' for detailed status), but lacks behavioral details like error handling, latency, or authentication requirements.

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 and adds return details efficiently in the second. Every sentence provides essential information with zero waste, making it appropriately sized and well-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 tool's low complexity (1 optional parameter, no output schema), the description is largely complete: it states the purpose, return values, and parameter effect. However, it lacks some behavioral context (e.g., error cases or performance expectations) that could enhance completeness.

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?

The schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that 'verbose' affects the output ('Include detailed status'), which clarifies the parameter's purpose beyond the schema's minimal description, justifying a score above 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 states the tool's purpose with specific verbs ('Check') and resources ('HashPilot MCP server health and status'), and distinguishes it from all sibling tools which focus on accounts, contracts, tokens, etc., not server health monitoring.

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 for checking server status, but provides no explicit guidance on when to use this tool versus alternatives (e.g., for debugging, monitoring, or initialization). 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.

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 adds useful context: 'FREE: No transaction fees (REST API query)' clarifies cost implications, and 'RETURNS: Balance, EVM address, creation time, keys, memo, transactions (optional)' outlines output behavior. However, it doesn't cover other key traits like rate limits, authentication needs, error handling, or pagination details, leaving gaps for a mutation-free query tool.

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 well-structured and front-loaded, starting with the core purpose. Each sentence adds value: the first states the action, the second lists returns, the third clarifies cost, and the fourth provides usage guidelines. There's no wasted text, and it's appropriately sized for the tool's complexity.

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

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 partially compensates by listing return values and cost details. However, for a query tool with 3 parameters and no structured output, it lacks information on response format (e.g., JSON structure), error cases, or limitations like rate limits. This makes it adequate but incomplete for full agent understanding.

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 documents all parameters (accountId, includeTransactions, transactionLimit) with descriptions. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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's purpose: 'Query comprehensive account data from Hedera Mirror Node REST API.' It specifies the verb ('query'), resource ('account data'), and source ('Hedera Mirror Node REST API'), making the action distinct. However, it doesn't explicitly differentiate from siblings like 'account_balance' or 'account_info', which might offer overlapping functionality, so it doesn't reach a perfect score.

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

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

The description provides clear usage context with 'USE FOR: Account inspection, transaction history, state verification.' This gives practical scenarios for when to use the tool. However, it doesn't specify when not to use it or name alternatives (e.g., 'account_balance' for just balances), so it lacks explicit exclusions or sibling comparisons.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by specifying what it returns (network name, Mirror Node URL, JSON-RPC Relay endpoint) and its use cases. However, it lacks details on potential errors, latency, or data freshness, which could be useful for an agent.

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 highly structured with clear sections ('RETURNS', 'USE FOR'), front-loaded with the core purpose, and uses only three concise sentences. Every sentence adds value without repetition or fluff, making it efficient for an agent to parse.

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 simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It covers purpose, returns, and usage guidelines. A minor gap is the lack of output format details (e.g., structure of returned data), but for a straightforward info tool, this is acceptable.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately omits parameter details, focusing instead on the tool's output and usage. This meets the baseline of 4 for tools with no parameters, as it avoids redundancy.

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 verb ('Get') and resource ('current Hedera network configuration'), making the purpose specific and unambiguous. It distinguishes itself from siblings like 'network_switch' (which changes networks) by focusing on retrieval of configuration data, not modification.

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 'USE FOR' section explicitly lists three scenarios: verifying active network, getting endpoint URLs, and checking network status. This provides clear, actionable guidance on when to use this tool, distinguishing it from alternatives like 'health_check' (which might test connectivity) or 'rpc_call' (which uses endpoints).

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?

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it switches networks 'seamlessly', updates 'All SDK connections, Mirror Node URLs, RPC endpoints automatically', and lists the four target networks. It doesn't mention side effects like session persistence or error handling, but covers the core behavior adequately.

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 three bullet-point sections (NETWORKS, UPDATES, USE FOR), each containing only essential information. Every sentence earns its place by clarifying scope, behavior, or usage without 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 moderate complexity (network switching with automatic updates), no annotations, and no output schema, the description is mostly complete. It covers purpose, networks, updates, and usage, but lacks details on return values or error conditions, which would be helpful for an agent invoking it.

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?

The input schema has 100% description coverage with a clear enum and description for the single parameter 'network'. The description adds minimal value beyond the schema by listing the network options in parentheses, but doesn't provide additional semantic context like default behavior or implications of each choice.

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's purpose with specific verbs ('Switch between Hedera networks') and resources ('SDK connections, Mirror Node URLs, RPC endpoints'), and distinguishes it from siblings like network_info by focusing on network switching rather than querying network 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 provides usage scenarios ('Multi-network development, testing across environments, production deployment'), giving clear guidance on when to use this tool versus alternatives like network_info for status checks or other tools for specific operations on a network.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: 'SUPPORTS: 55+ methods including eth_*, web3_*, net_*, debug_*' (scope), 'DECODES: Results automatically converted to human-readable format' (output processing), and 'USE FOR: EVM-compatible operations... transaction submission' (capabilities). However, it doesn't mention rate limits, authentication requirements, or error handling patterns.

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 perfectly structured with clear sections (SUPPORTS, EXAMPLES, DECODES, USE FOR) and every sentence earns its place. It's front-loaded with the core purpose, uses bullet-like formatting for readability, and contains zero wasted words while conveying essential information.

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 tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description does well by explaining scope (55+ methods), providing examples, describing output processing (decoding), and giving usage guidelines. However, it could better address the lack of output schema by describing typical return formats or error patterns for this RPC interface.

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 documents all three parameters thoroughly. The description adds minimal value beyond the schema - it provides example method names ('eth_blockNumber, eth_getBalance, eth_call, eth_getLogs, eth_sendRawTransaction') which help illustrate the 'method' parameter, but doesn't add significant semantic context about parameter usage or constraints 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 tool's purpose with specific verbs ('Execute ANY JSON-RPC method') and resources ('on Hedera's JSON-RPC Relay'). It explicitly distinguishes this tool from siblings like rpc_call_contract, rpc_deploy_contract, and rpc_execute_contract by emphasizing its general-purpose nature for ANY JSON-RPC method rather than contract-specific operations.

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 explicit usage guidance with 'USE FOR: EVM-compatible operations, blockchain state queries, transaction submission.' It distinguishes when to use this tool (general JSON-RPC) versus contract-specific siblings (rpc_call_contract, etc.) and lists example methods to clarify appropriate use cases.

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?

With no annotations provided, the description carries full burden and does well: it discloses key behavioral traits including 'read-only', 'no state changes', 'FREE - no gas cost', and 'DECODES: Return values using provided ABI'. It doesn't mention rate limits or specific error conditions, but covers the essential safety and cost profile.

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?

Highly structured with bullet-like sections (EXECUTES, DECODES, FREE, USE FOR), front-loaded with the core purpose, and every sentence earns its place. No wasted words while maintaining clarity.

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 no annotations and no output schema, the description does well: covers purpose, usage, behavioral traits (safety, cost, decoding). It doesn't describe return format or error handling, but given the context (simple query tool with good schema coverage), it's mostly complete.

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 documents all 4 parameters. The description mentions 'provided ABI' and 'function to call' but doesn't add meaningful semantic context beyond what the schema provides (like format details or examples). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action: 'Call read-only smart contract function via eth_call' with the resource being smart contracts. It distinguishes from siblings like rpc_execute_contract (which likely writes) by emphasizing 'read-only' and 'FREE - no gas cost'.

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?

Explicitly states when to use: 'USE FOR: Reading contract state, querying balances, checking conditions.' This provides clear context and distinguishes from write operations. The 'FREE - no gas cost' also implies when not to use (for state-changing operations).

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it handles 'bytecode deployment, constructor encoding, gas estimation, receipt polling,' returns 'contract address, transaction hash, deployment details,' incurs 'gas fees for contract creation,' and has an 'AUTO-KEY' feature for optional private key usage. However, it lacks details on error handling, rate limits, or specific gas estimation methods, preventing a perfect score.

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 well-structured with sections (HANDLES, RETURNS, COSTS, AUTO-KEY, USE FOR) and front-loaded key information. Each sentence earns its place by providing essential details without redundancy, such as clarifying the optional private key and specifying the target (Hedera EVM). It avoids unnecessary elaboration while covering critical aspects efficiently.

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 smart contract deployment and no output schema, the description does a good job covering inputs, behaviors, and outputs. It explains what the tool handles, returns, costs, and key parameter usage. However, without annotations or an output schema, it could benefit from more detail on error cases or the structure of 'deployment details,' slightly reducing completeness for this advanced 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 description coverage is 100%, providing a baseline of 3. The description adds some value by explaining that 'privateKey is OPTIONAL - automatically uses MCP operator account if not provided,' which clarifies usage beyond the schema's 'optional' note. However, it does not elaborate on the semantics of 'bytecode,' 'abi,' or 'constructorArgs' beyond what the schema already describes (e.g., format details for constructor arguments).

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 ('Deploy smart contract') and target resource ('to Hedera via JSON-RPC'), distinguishing it from sibling tools like 'deploy_contract' (which may use a different method) and 'rpc_call_contract' (which calls existing contracts). It includes the implementation details (bytecode deployment, constructor encoding, etc.) that further clarify its unique 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?

The description explicitly states 'USE FOR: Deploying Solidity contracts to Hedera EVM,' providing clear context for when to use this tool. It also distinguishes it from alternatives by specifying 'via JSON-RPC' (unlike 'deploy_contract' which might use other protocols) and mentions the optional 'privateKey' parameter with automatic fallback to the MCP operator account, guiding usage decisions.

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?

With no annotations provided, the description carries full burden and excels by disclosing critical behavioral traits: it's state-changing (modifies contract state), handles function encoding/signing/gas estimation/receipt polling, incurs gas costs, returns transaction hash/receipt/decoded logs, and has automatic key management. This covers mutation, costs, return format, and authentication 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 efficiently structured with clear sections (EXECUTES, HANDLES, COSTS, RETURNS, AUTO-KEY, USE FOR), each containing one sentence or phrase. Every element adds value with zero wasted words, making it easy to scan and understand.

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 complex state-changing tool with no annotations and no output schema, the description provides comprehensive context: purpose, behavioral traits (mutation, costs, return format), usage guidelines, and key parameter clarification. It fully compensates for the lack of structured metadata.

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 documents all 6 parameters. The description adds minimal parameter-specific semantics beyond the schema, only clarifying that privateKey is optional and auto-uses MCP operator. This meets the baseline of 3 when schema coverage is high.

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

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

The description explicitly states the tool's purpose as 'Execute state-changing contract function via eth_sendRawTransaction' and specifies it's for 'Token transfers, contract interactions, state modifications.' This clearly distinguishes it from sibling tools like rpc_call (likely read-only) and rpc_deploy_contract (for deployment).

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 explicit guidance with 'USE FOR: Token transfers, contract interactions, state modifications' and distinguishes it from alternatives by noting it handles 'EXECUTES: Transaction that modifies contract state' (versus read-only calls). The AUTO-KEY section also clarifies when to provide privateKey versus using the MCP operator.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by describing role-based controls, compliance features, and dangerous operations like 'delete' with DANGER warning. However, it lacks details about authentication requirements, rate limits, error handling, or what happens when operations fail.

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 well-structured with clear sections (OPERATIONS, FEATURES, AUTO-CONFIG, USE FOR) and efficiently communicates complex functionality. While comprehensive, it could be more front-loaded with the most critical information rather than burying the 'USE FOR' section at the end.

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 complex tool with 27 parameters, no annotations, and no output schema, the description provides good operational overview but lacks critical behavioral details. It doesn't explain return values, error conditions, or provide examples of successful usage patterns. The absence of output schema means the description should compensate more with expected response information.

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 documents all 27 parameters thoroughly. The description adds value by explaining the purpose of operations and features like role-based access control, but doesn't provide additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose as 'Enterprise-grade stablecoin management via Hedera Stablecoin Studio' and lists 18 specific operations. It distinguishes itself from sibling tools like 'token_manage' by focusing specifically on stablecoins with compliance features and role-based controls.

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 with 'USE FOR: Institutional stablecoin issuance, compliance workflows, token lifecycle management' which gives appropriate usage scenarios. However, it doesn't explicitly state when NOT to use this tool or provide direct alternatives to 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?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: backup excludes private keys by default for security, restore can merge or replace, and export produces JSON for inspection/sharing. It doesn't mention potential side effects, error conditions, or performance characteristics, but provides solid operational context.

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

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

The description is perfectly structured and front-loaded: first sentence states the core purpose, followed by clear operation definitions, then usage guidelines. Every sentence earns its place with zero waste. The bullet format enhances readability without sacrificing conciseness.

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 state management tool with 6 parameters, 100% schema coverage, and no output schema, the description provides strong context about operations and use cases. It could be more complete by mentioning what 'state' specifically includes or providing examples of when to choose backup vs export, but it covers the essential behavioral aspects well given the structured data available.

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 baseline is 3. The description adds minimal parameter semantics beyond the schema - it mentions timestamped backups, JSON export format, and merge/replace behavior, but these are largely implied by parameter names. The description doesn't significantly enhance understanding of individual parameters beyond what the schema provides.

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's purpose with specific verbs ('manage', 'backup', 'restore', 'export') and resources ('HashPilot MCP server state'). It distinguishes itself from all sibling tools by focusing on state management operations rather than account, contract, network, or documentation functions.

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 'USE THIS FOR' section explicitly provides usage contexts: 'State persistence, migration, disaster recovery, debugging.' This gives clear guidance on when to select this tool versus the many sibling tools for different purposes like account management, contract deployment, or network operations.

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?

With no annotations provided, the description carries full burden. It effectively discloses key behavioral traits: it's a unified interface for multiple operations, requires specific keys for different operations (admin/supply/freeze/kyc/wipe/pause), and mentions prerequisites like association before receiving tokens. However, it doesn't cover rate limits, error conditions, or transaction costs.

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 well-structured with clear sections (OPERATIONS, USE THIS FOR, REQUIRES) and uses bullet points for readability. While comprehensive, it could be more concise by reducing some redundancy in operation explanations. Every sentence adds value, but the overall length is substantial for a single tool.

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 complex tool with 17 parameters, no annotations, and no output schema, the description does a good job covering purpose, usage, and behavioral context. It explains the unified interface approach, lists all operations with brief explanations, and specifies key requirements. The main gap is lack of output format information, which would be helpful given the diverse operations.

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 documents all 17 parameters. The description adds some context by grouping parameters with operations (e.g., 'for create', 'for transfer'), but doesn't provide significant additional semantic meaning beyond what's in the schema descriptions. This meets the baseline 3 for high 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?

The description clearly states this is for 'Comprehensive Hedera Token Service (HTS) management' and lists 12 specific operations with brief explanations. It distinguishes itself from sibling tools like 'transfer_hbar' and 'stablecoin_manage' by focusing exclusively on token operations rather than HBAR transfers or stablecoin-specific functions.

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 'USE THIS FOR: All token lifecycle management, compliance operations, supply control, and transfer operations' and 'REQUIRES: Operator account with appropriate keys... based on operation.' This provides clear when-to-use guidance and prerequisites, though it doesn't explicitly mention when NOT to use it versus 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains execution details (CryptoTransfer transaction), prerequisites (operator account requirements), and costs (standard network transaction fee), covering key behavioral aspects beyond basic functionality.

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

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

The description is well-structured with clear sections (purpose, execution, requirements, costs, usage) and uses bullet-like formatting. Every sentence adds value with no redundancy, making it efficiently front-loaded and easy to parse.

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

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

For a mutation tool with no annotations and no output schema, the description does well by covering purpose, execution, requirements, costs, and usage scenarios. It could improve by mentioning error cases or response format, but it's largely complete given the context.

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 documents all three parameters (from, to, amount). The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or constraints, meeting the baseline for high 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?

The description clearly states the specific action ('Transfer HBAR') and resource ('between Hedera accounts'), distinguishing it from sibling tools like account_balance or token_manage. It explicitly mentions executing a CryptoTransfer transaction, which provides precise operational context.

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 includes a 'USE FOR' section listing specific scenarios (funding accounts, payments, moving HBAR between wallets), which gives clear context for when to use this tool. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings.

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?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it lists three verification methods (Direct source upload, Hardhat build-info, Foundry artifacts) and describes what the tool returns (verification status and HashScan URL). This provides important operational context beyond basic parameters.

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 perfectly structured with clear sections (METHODS, RETURNS, USE FOR) and every sentence earns its place. It's front-loaded with the core purpose and efficiently communicates essential information without wasted words.

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 (4 parameters, no output schema, no annotations), the description provides good coverage of what the tool does, how it behaves, and when to use it. The main gap is lack of output schema, but the description compensates by specifying what the tool returns. It could be more complete by explaining parameter relationships or error cases.

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 75% (3 of 4 parameters have descriptions), so the baseline is 3. The description doesn't add meaningful parameter semantics beyond what's in the schema - it mentions verification methods but doesn't explain how they relate to the filePath parameter or other inputs. The description doesn't compensate for the 25% coverage gap.

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 ('verify smart contract') and resource ('on HashScan block explorer'), distinguishing it from sibling tools like deploy_contract or rpc_call_contract which focus on different operations. It provides concrete purpose beyond just 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 'USE FOR' section explicitly lists three use cases (contract transparency, code verification, public auditability), giving clear context about when this tool is appropriate. However, it doesn't specify when NOT to use it or mention alternatives among siblings like foundry_contract or hardhat_contract that might relate to verification.

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