avalanche-mcp-server

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context: it is offline (no network dependency) and sourced from a specific repository. This goes beyond the annotations and informs the agent of the data source and availability, though it does not discuss pagination or limits, which are minor for a list 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 three sentences long, packs the core purpose, output fields, and usage examples with zero fluff. It is front-loaded with the main verb and resource, making it scannable for an agent.

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 there is no output schema, the description compensates by listing the fields returned (number, title, status, track, authors, replaces/dependencies). It also explains the offline nature and example queries. Minor omissions like pagination or ordering are not significant for a list tool, so the description is largely 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 has only 50% coverage (track described, status not). The description compensates by explicitly listing the allowed values for both status and track, enriching the meaning of both parameters beyond the schema. This bridges the gap left by the missing status description.

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 'List' and resource 'ACPs', enumerates the structured fields returned, and mentions the offline parsing from avalanche-foundation/ACPs. It distinguishes from sibling avax_acp_lookup by focusing on listing all proposals, though it does not explicitly name that sibling. The purpose is unambiguous.

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

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

Provides concrete example queries ('which upgrades are live?', 'what changed in Etna/Fortuna?') that frame when to use the tool. It does not explicitly state when not to use it or name alternatives, but the examples give clear contextual guidance for listing ACPs versus more targeted lookups.

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

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive), so the burden is lighter. The description adds genuinely useful behavioral context: the full text is returned truncated, and the tool works offline. No contradiction with annotations, and no misleading mutation claims.

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?

One compact sentence that front-loads the action and query method, then packs the return fields and the offline behavior. Zero filler. Every clause earns its place.

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

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

For a single-required-parameter lookup tool whose safety profile is already carried by annotations, the description is largely sufficient: it specifies the query key, enumerates the returned fields, and notes truncation. Minor gaps remain (no-results behavior, truncation length, full_text semantics), but they don't block correct invocation.

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

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

Schema coverage is 50% — the query param is described with examples ('77', 'ACP-176', 'reinventing subnets'), which covers query semantics well. The description reinforces this ('by number or title keyword'). However, the full_text boolean has no schema description and is only implied in the description via 'full text (truncated)'; its default and effect on the response are not explained, so the 50% coverage gap is only partially compensated.

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

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

The description states a specific verb ('Get one ACP') and resource, and clarifies the lookup key ('by number or title keyword'). It also enumerates the returned fields (preamble, abstract, full text). It doesn't name siblings, but 'Get one' implicitly contrasts with the avax_acp_list sibling, which is enough to orient an agent.

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 when to use it — when you have a specific ACP number or title keyword — since it returns one record. However, it never explicitly states when not to use it or which sibling to prefer (e.g., avax_acp_list for listing all, avax_search_docs for broader doc search). The 'Offline' note hints at a distinguishing use case but doesn't connect it to a live alternative like avax_fetch_live_doc.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds useful behavioral context beyond this: it notes that the query hits a public node and that the result is empty when no ACP vote is in progress. This helps the agent understand the real-time nature and the edge case, adding value beyond the annotations.

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

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

The description is two concise sentences with no wasted words. It front-loads the core action and resource, then immediately covers the network option and the empty-result caveat. Every sentence earns its place, and the structure is easily skimmable.

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 (one optional parameter, read-only, no output schema), the description is complete. It covers the purpose, the network choices, the empty behavior, and implicitly the data being returned. Annotations handle safety, and there are no unresolved ambiguities for an agent to call this correctly.

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% description coverage, so the description must compensate. It explicitly mentions 'mainnet or fuji', which aligns with the network enum, thereby clarifying the sole parameter. It also implies the parameter is optional by focusing on the query action. This is sufficient for the single, simple parameter, and the description adds meaning beyond the raw enum.

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

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

The description states a specific verb ('Query') and resource ('public node's info.acps') and clearly describes what it returns (ACPs currently being signaled with supported/objected weight). It also specifies the networks. However, it does not explicitly differentiate from sibling tools like avax_acp_list or avax_acp_lookup, so while the purpose is clear, it relies on the agent to infer the distinction.

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 some usage context: it mentions the network selection and clarifies the empty result when no vote is in progress. It does not, however, state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The intended use case is implied but not contrasted with sibling ACP tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clearly disclosed. The description adds useful context about accepted network identifiers and an example signature. However, it does not mention the return value shape (e.g., decoded result) or what happens on revert, which would add value beyond annotations. No contradiction with annotations.

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

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

The description is two concise sentences. The first front-loads the purpose and includes an example, the second lists network options. It is efficient and well-structured, though the network enumeration is slightly verbose and could be streamlined.

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?

With no output schema, the description should hint at the return format (e.g., decoded return value of the function) and failure behavior (e.g., reverts). It only covers input specification, leaving the agent unaware of the response shape or error handling. For a tool with 4 parameters and non-trivial call semantics, this is a noticeable 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 coverage is 100% with clear descriptions for address, signature, args, and network. The description adds an example of the signature format and notes 'big numbers as decimal strings' for args (also present in schema). It does not introduce new meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the specific action: 'Call a read-only (view/pure) contract function' and provides an example signature format. It distinguishes from sibling tools like avax_get_balance (which reads a known balance) or avax_get_code (which reads code) by focusing on arbitrary contract function calls. However, it does not explicitly name a sibling to avoid confusion, so it's not a 5.

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

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

The description explains how to provide the signature, args, and network, but does not explicitly compare this tool with alternatives or state when not to use it. It implies usage for read-only contract calls for any EVM contract, leaving the agent to infer that other tools like get_balance are for specific predefined reads. No exclusions or conditional guidance is given.

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

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

Annotations already mark this as readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's addition of return content (deep links, platform-cli equivalents) and filtering behavior adds practical context. The description aligns with annotations and goes beyond them by specifying what data is returned.

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 concise, starting with the core action and list of flows, then adding the parameter tip. It's front-loaded and every sentence adds value. A slightly more structured format could separate the flow list from the parameter note, but overall it's efficient.

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

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

For a simple listing tool with one optional parameter, the description covers the main usage: listing flows and filtering. It also mentions platform-cli equivalents, which helps in scriptable contexts. It doesn't describe the return structure explicitly, but given no output schema and simplicity, it's reasonably 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?

The input schema has 0% description coverage on the `flow` parameter, but the description explicitly explains 'Pass `flow` for one entry,' giving the parameter purpose. It doesn't enumerate valid values but the flow names are listed earlier, providing indirect meaning. This compensates adequately for a single optional parameter.

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 lists Builder Console flows with deep links, enumerating specific flow names. It's specific about the resource (Builder Console) and the action (list), and differentiates from sibling tools by focusing on console flows and platform-cli equivalents, which none of the other tools do.

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

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

The description mentions passing `flow` to get a single entry, providing some usage guidance. However, it does not contrast with alternatives like avax_plan_l1_launch or avax_icm_recipe, nor does it state when to prefer this tool over others. The usage context is implied (for listing console flows) but lacks explicit exclusions or comparisons.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by listing the specific metadata fields returned (type, name, symbol, decimals, deployment tx), which is useful context the annotations do not cover. However, it does not disclose any additional behavioral nuances such as timeout, rate limits, or error scenarios.

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?

One sentence, front-loaded with the core purpose, and includes the most relevant output fields. No wasted words or repetitive 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 read-only metadata fetch with two parameters and no output schema, the description is adequate. It names the API and lists the returned fields. The annotations cover safety, and the schema handles parameter details. It lacks explicit guidance on the return format or edge cases, but for this simple tool the information is sufficient.

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

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

Schema coverage is 50%: chain_id has a description, address does not. The description adds only the term 'contract' to clarify address's role, but does not explain address format requirements or elaborate on chain_id's accepted values (already in schema). It does not compensate for the missing address description, so the agent gets little extra semantic guidance beyond 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 states a specific verb ('Get metadata'), a resource ('contract address'), and enumerates the exact fields returned (ERC-20/721/1155 type, name, symbol, decimals, deployment tx). This clearly distinguishes it from sibling tools like get_balance or get_block, which target different resources.

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 by specifying it retrieves metadata for a contract address via the Avalanche Data API. While it does not explicitly name alternative tools or when not to use it, the context is sufficient for a reasonable agent to infer this is the go-to tool for token metadata. No exclusionary guidance is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about the data source (Glacier API) and return fields, but does not disclose behavioral details like pagination, result limits, or what happens when the network filter is omitted. With annotations carrying the safety profile, a 3 is appropriate.

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

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

Two front-loaded sentences with zero filler. The main action and resource lead, followed by data fields and the usage note. Slightly more relational than strictly necessary, but each part earns its place and it is easy for an agent to parse quickly.

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

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

Complete for a simple discovery tool: one optional parameter fully documented in schema, strong annotations covering safety, and a description that states scope, return fields, and the primary use case. Minor gaps remain — no mention of result ordering, pagination, or default behavior when network is absent — but for a list tool these are low-impact.

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% — the single optional 'network' parameter is already documented ('Filter by environment' with mainnet/testnet enums). The description does not add parameter-specific guidance, so the schema does the heavy lifting, warranting the baseline 3.

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

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

States a specific verb+resource ('List every chain (C-Chain + L1s) indexed by the Avalanche Data API') and enumerates the exact data returned (chain ID, name, RPC, explorer, native token, testnet flag). It also distinguishes itself from the built-in registry, helping an agent tell it apart from siblings like avax_list_networks.

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?

'Best way to discover L1s beyond the built-in registry' frames when to prefer this tool and implies the built-in registry is covered elsewhere (i.e., avax_list_networks). It gives clear context for the L1-discovery use case, though it does not explicitly name the sibling to use when the built-in registry is needed.

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?

Read-only and idempotent behavior is already covered by annotations, so the description does not need to restate it. It adds a useful behavioral contract by specifying exactly what is returned: token address, symbol, decimals, and balance. It does not discuss pagination limits, but that is a minor gap for this kind of listing 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 two tight sentences: one for the operation and one for the return shape. Nothing is redundant or marketing-heavy, so an agent can parse it quickly.

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 moderate 3-parameter tool with strong annotations and no output schema, the description gives the core information needed to call it: purpose, owner-address parameter, chain context, and return fields. It could mention the default chain_id or pagination behavior, but the input schema already exposes those details.

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

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

Schema coverage is only 33%, and the description partly compensates by clarifying that address is the holder and 'on a chain' scopes chain_id. However, page_size semantics and address format expectations are not elaborated, leaving some parameter meaning to reliance on property names and schema defaults.

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 is specific: 'List all ERC-20 token balances held by an address on a chain.' It names the exact resource type, the required scope/owner, and the return fields, making it immediately distinguishable from generic balance and transaction tools.

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 clearly states when this tool fits: when an agent needs ERC-20 balances for a specific address on a supported chain. It does not explicitly call out native-balance alternatives or say 'use avax_get_balance instead,' so it falls short of full routing guidance.

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

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

Annotations already convey readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful context: scope ('post-Etna ACP-77') and the returned fields (weight, balance, remaining balance owner). It does not mention pagination or rate limits, but those are secondary given the annotation coverage.

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

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

The description is a single, dense sentence with no filler. Purpose, scope, filters, and output fields are all front-loaded, making it trivially quick 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?

With no output schema, the description must explain the return shape; it lists three output fields but omits pagination behavior, ordering, and other likely list fields. The page_size parameter is present in the schema but never explained, leaving gaps for a complete 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 0%, so the description must explain parameters. It mentions subnet_id and node_id as filters but says nothing about network or page_size semantics. The network enum and page_size bounds exist in the schema, but their meaning and behavior are not clarified, leaving half the parameters under-documented.

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

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

The description states a specific verb and resource: 'List sovereign L1 validators (post-Etna ACP-77) from the Data API'. It also mentions optional filters by subnet or node ID and the output fields, making it clearly distinct from sibling tools like avax_pchain_get_validators.

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

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

The phrase 'from the Data API' and 'post-Etna ACP-77' imply when this tool is appropriate, but no explicit when-to-use or when-not-to-use guidance is provided. It does not name alternatives or exclusions, leaving the agent to infer from the tool name and 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds behavioral context by specifying that it lists both native and contract interactions and is paginated, which is not in the annotations. The description aligns with the read-only nature and does not contradict any annotations.

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

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

The description is a single, tight sentence that front-loads the purpose and scope. It includes necessary context (API source, pagination) without unnecessary words, making it efficient 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 tool with 4 parameters and no output schema, the description is thin. It mentions pagination but not how to use page_token, what the response contains, or any prerequisites (e.g., chain_id defaults). While the schema covers requiredness and defaults, the description leaves gaps on return structure and pagination mechanics, making it only marginally complete for an agent to call correctly.

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 only 25% (only chain_id has a description). The description does not elaborate on the address format, page_size constraints, or page_token usage. Since schema coverage is low, the description must compensate, but it does not provide additional parameter-level meaning beyond the general context, leaving agents to guess on critical parameters like page_token.

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

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

The description clearly states a specific verb ('List') and resource ('recent transactions of an address on a chain'), includes the scope ('native + contract interactions'), and identifies the underlying API. This distinguishes it from sibling tools like avax_get_transaction (single transaction) and avax_data_list_erc20_balances (balances) without ambiguity.

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 conveys the core function and the pagination aspect, but it does not explicitly state when to use this tool versus alternatives such as avax_get_transaction for a single transaction or avax_data_list_chains for chain listings. Usage guidance is implied by the tool name and context, not explicitly articulated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by mentioning that the tool returns the current base fee, which helps the agent understand output beyond the name. It does not contradict annotations.

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

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

The description is two clear sentences, with the primary function and key output stated first, followed by network details. No fluff or redundant phrasing; it is front-loaded and efficient.

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

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

For a read-only tool with no output schema, the description explains the main return (gas estimate and base fee) and covers network selection details. It does not specify the exact output format, but given the annotations cover safety and the function is simple, it is sufficiently complete for an agent to call correctly.

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 all parameters are already documented. The description lists the parameters (to, data, value, from) but uses 'value' instead of the schema's 'value_wei', which is a minor inconsistency. It adds little beyond what the schema already provides, so it meets the baseline without significant added 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 states that the tool estimates gas for a transaction, explicitly listing the relevant parameters (to, data, value, from), and notes it also returns the current base fee. This is specific and differentiates it from sibling tools like avax_call_contract or avax_get_transaction.

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 when an agent needs a gas estimate and a base fee for budgeting, but it does not explicitly compare with alternatives or state when not to use this tool. There is no mention of 'use X instead' or exclusions, so guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and idempotent=true, so the description doesn't need to restate safety. It adds a list of returned content (address, genesis key, etc.) and mentions 'most relevant doc hits', which implies the output may include references. It doesn't describe error behavior, but for a read-only tool this is minor and the description is consistent with annotations.

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

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

A single, well-structured sentence that front-loads the purpose ('Reference card') and then uses a colon to enumerate the content. There is no fluff or repetition; every phrase adds 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?

For a tool with one enum parameter and read-only annotations, the description sufficiently outlines the output content (address, genesis config key, purpose, example snippet, Solidity notes, doc hits). It doesn't specify output format or error cases, but given the simple nature and existing annotations, it is largely complete. It would benefit from explicitly mentioning the 'name' argument.

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 has one parameter 'name' with an enum of precompile names, but the description never mentions this parameter or explains that it selects which precompile. With schema description coverage at 0%, the description should clarify the argument's role, but it only says 'one Subnet-EVM precompile' without tying it to the input. This is a significant 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 it provides a reference card for a Subnet-EVM precompile, listing specific content (address, genesis config key, purpose, genesis snippet, Solidity notes, doc hits). It distinguishes from siblings like avax_get_doc or avax_search_docs by focusing on a single precompile's reference information, not general documentation 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 description provides no explicit when-to-use guidance, no mention of alternative tools, and no conditions for when this tool is preferable over related siblings like avax_get_doc or avax_list_topics. The phrase 'Reference card' implies a quick lookup, but there is no concrete usage context or exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which cover the safety profile. The description adds value by noting the tool fetches the 'CURRENT' version (implying possible divergence from local cache) and that output is 'clean markdown' via the .md endpoint, providing behavioral context beyond the schema.

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

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

The description is two sentences, with the primary purpose front-loaded and usage guidance following immediately. Every phrase contributes either to scope, freshness, or fallback conditions, with no filler.

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

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

For a simple fetch tool, the description covers what it does, when to use it, and the input format. The missing offset explanation is the only notable gap, but given the tool's low complexity and the annotations covering side effects, it is otherwise complete enough for an agent to call correctly.

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

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

Schema coverage is 50% (url described, offset not mentioned). The description restates the url format ('full URL or site path') but adds no detail beyond the schema's own description. The offset parameter is completely undocumented in both schema and description, leaving an agent without any clue as to its purpose or effect.

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 fetches the CURRENT version of any build.avax.network page as markdown, enumerating the page types (docs, academy, integrations, blog, acps) and the mechanism (official .md endpoint). This distinguishes it from local-index tools like avax_get_doc or avax_list_docs by emphasizing freshness.

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

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

It explicitly specifies when to use this tool: when the local index may be stale (check builtAt in avax_list_topics) or for pages not indexed. This gives clear contextual triggers, though it does not name the exact alternative tool to switch from, relying on the reader to infer that avax_get_doc is the local-index counterpart.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine value on top: it discloses the warp-on-by-default behavior with a rationale ('ICM/Teleporter needs it') and states the return shape ('Returns the JSON plus next-step CLI commands'). No contradiction with the annotations.

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

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

Three sentences with the core purpose front-loaded. The middle sentence is a dense but informative enumeration of options, and the final sentence captures the return contract in six words. No filler or redundant restatement of the title.

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 this complex (14 parameters, nested allocations object, no output schema), the description covers the main config categories and the return format, but it does not clarify the required chain_id constraint or explain what each precompile actually does. It is adequate but leaves the agent to open the schema for the full picture.

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 schema description coverage at only 29%, the description must carry more weight, and it does partially: it enumerates the fee_preset enum values (low|medium|high|gasless), the precompile toggles (deployer allow-list, tx allow-list, native minter, fee manager, reward manager, warp), and allocations. However, it omits chain_id — the only required parameter — plus admin_address and reward_address, leaving a meaningful gap for the agent on what is mandatory.

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

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

The description opens with a specific verb+resource+context: 'Generate a valid Subnet-EVM genesis.json for a new Avalanche L1.' This clearly differentiates it from the sibling list, which is dominated by query tools (get_balance, get_block, data_list_*) and doc tools — none of them generate genesis config. The purpose is unambiguous and immediately understood.

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?

Usage context is implied ('for a new Avalanche L1', 'next-step CLI commands') and the config options suggest scenarios, but there is no explicit when-to-use vs when-not-to-use guidance, and no alternative is named. Notably, the sibling avax_plan_l1_launch sits adjacent to this workflow but the description never routes the agent between them.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds value beyond annotations by detailing that the tool works across specific networks and L1 keys, and that it returns both wei and formatted values. This complements the annotations without contradicting them.

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 two sentences, front-loaded with the primary action and scope. It efficiently covers network options and return information without fluff. Every sentence earns its place, and there is no unnecessary repetition or verbiage.

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, an output schema exists to define the return structure, and the description complements it with concrete network details and return format. It covers all required information for an agent to select and invoke the tool correctly: what it does, which networks it operates on, and what it returns. Nothing essential is missing.

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

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

Schema coverage is 100%—both parameters have descriptive text in the schema. The description repeats the network list and return format but adds no new meaning beyond what the schema provides. Since the schema already documents the parameters thoroughly, a baseline 3 is appropriate; the description does not elevate understanding further.

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 a specific verb and resource: "Get the native token balance" of an address on an Avalanche EVM chain. It distinguishes from sibling balance tools (e.g., avax_pchain_get_balance, avax_xchain_get_balance) by scoping to EVM chain native tokens. The network options are explicitly enumerated, leaving no ambiguity about what this tool does.

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 on when to use the tool: for querying native AVAX balance on C-Chain or Fuji, or native token on a listed L1. It does not explicitly name alternative tools for P/X-chain balances, but the scope is implied to be EVM-only, which sufficiently guides selection. A minor gap is the lack of an explicit 'for other chain balances use X' statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that: it discloses the return shape (header fields plus transaction hashes) and the include_transactions toggle behavior, and it enumerates the network targeting options including an arbitrary full RPC URL, which is meaningful behavioral context consistent with openWorldHint.

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

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

Two dense sentences with no filler. Core information (what is fetched, by what keys, what is returned) is front-loaded, followed by the network options. The second sentence runs long due to the enumerated network names, but every clause earns its place.

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

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

For a read-only fetch tool with no output schema, the description covers the essential ground: block identifiers, return contents, the boolean toggle, and the complex network parameter. It does not enumerate the exact header fields returned or the full RPC URL requirements, but given the annotations and moderately simple parameter set, nothing critical an agent needs to call it correctly is missing.

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

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

Schema coverage is 67% — block and network carry schema descriptions, but include_transactions has none. The description partially compensates by explaining that include_transactions=true yields full tx objects instead of hashes, adding meaning beyond the schema. Yet the network parameter semantics are already fully described in the schema, so the net added value is moderate.

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

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

States a specific verb+resource ('Fetch a block') with the identification methods (number, hash, tag) and its scope. It is clearly distinguishable from avax_get_transaction, avax_get_balance, and avax_get_chain_status by the block-specific resource, so an agent can tell it apart without opening those sibling schemas.

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 purpose implies when to use it — when a block is needed — and the include_transactions hint implicitly guides granularity choice. However, the description gives no explicit when-not guidance or alternative routing (e.g., contrast with avax_get_transaction or avax_data_list_transactions), leaving selection to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond that: it lists what data will be returned (chainId, block number, base fee, gas price) and supports network selection via a flexible set of keys or a full RPC URL. This is useful for an agent to anticipate the tool's behavior without opening the schema. It does not describe error handling or output format, but the annotation coverage plus the listed fields make this a strong 4.

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

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

Two sentences, zero fluff. The first sentence states the tool's function and return fields; the second enumerates network options. Every phrase earns its place, and the core purpose is front-loaded before the network details. It is efficiently structured for quick parsing.

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 one optional parameter (defaulted), no required inputs, no output schema, and a read-only/idempotent annotation set, the description fully covers what an agent needs: what it does, what it returns, and how to specify the network. Nothing essential is missing for correct invocation.

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

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

The schema description for the single parameter 'network' is identical to the tool description's network line (100% schema coverage). The tool description repeats that information verbatim rather than adding new parameter semantics. It does provide the use-case context ('verify RPC works'), but that is more tied to the tool purpose than to parameter meaning. With full schema coverage, baseline 3 is appropriate.

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

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

States a specific verb ('Get') and resource ('live status of an Avalanche EVM chain'), and enumerates the exact data returned: reported chainId, latest block number, base fee, gas price. It also names the primary use case (verify RPC works, pick gas settings), which distinguishes it from sibling tools like avax_get_block or avax_get_balance that target specific blocks or balances.

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 the tool: 'Useful to verify an RPC works and to pick gas settings.' This gives clear context for invocation. It does not name alternatives or exclusion conditions, but since the tool is unique (no other chain-status sibling), the guidance is adequate and no alternative routing is necessary.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds value by specifying exactly what the tool returns (a boolean indicator, bytecode size, and bytecode prefix) and by detailing the network options. This goes beyond the bare annotations and clarifies the tool's observable 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 two concise sentences, with the primary purpose and output front-loaded in the first sentence and network details in the second. Every word contributes—no filler or redundancy. This is an excellent example of compact, high-signal writing.

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 only two parameters and no output schema, the description covers the essential context: what it does, when to use it, and the valid network selection. It does not describe the exact return format (e.g., JSON structure) but the textual description of returning 'whether an address is a contract, bytecode size, prefix' gives the agent enough to understand the result. No critical detail seems missing.

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% coverage of both parameters, including descriptions for address ('0x-prefixed 20-byte EVM address') and network (listing all valid network keys). The description adds little new information about parameters—it essentially reiterates the network options and adds the 'verify deployments' context, but does not elabare on parameter formats or edge cases. Baseline 3 is appropriate since the schema handles parameter documentation.

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

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

The description clearly states what the tool does: 'Return whether an address is a contract and its bytecode size (and bytecode prefix).' This is a specific verb ('Return') and resource ('address contract code'), and the title reinforces the purpose. It distinguishes itself from siblings like avax_get_balance or avax_call_contract by focusing on code presence and size.

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 a clear use case: 'Use to verify deployments.' This gives the agent a concrete scenario for when to invoke this tool. It does not explicitly name alternatives or state when *not* to use it, but the narrow scope (contract code vs. balance/transactions) makes the intended usage reasonably unambiguous.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat those. It adds valuable context about truncation at 25k chars and the `offset` mechanism to continue reading, which is beyond what annotations and schema provide. No contradiction.

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

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

Two sentences, no fluff. The primary purpose is front-loaded, and the truncation detail is stated succinctly as an important behavior. Every word earns its place.

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

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

For a read-only doc fetch tool with no output schema, the description covers the key aspects: how to specify the path, the truncation limit, and offset continuation. It doesn't elaborate on error handling, but that's not critical for this simple tool. Overall complete for an agent to call it correctly.

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

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

Schema coverage is only 50% (offset lacks a description). The description compensates by explaining `path` can come from search/list or a URL, and explicitly states `offset` is used to continue after truncation. This adds meaning to both parameters, especially offset, which is otherwise undocumented.

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

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

States the action (return full text), the resource (documentation page), and explicitly identifies how to specify it via `path` from avax_search_docs/avax_list_docs or a URL. This makes the purpose clear and distinguishes it from sibling tools like avax_get_guide or avax_fetch_live_doc.

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?

Clearly indicates the path source (from avax_search_docs/avax_list_docs), implying those are prerequisite tools for finding pages. Also explains the truncation and continuation behavior, which guides when to use `offset`. However, it does not explicitly state when not to use this tool versus similar alternatives, so not a full 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the content of each guide (e.g., 'addresses, genesis keys and when to use each of the 6 built-in precompiles'), informing the agent what will be returned. It does not mention response format, but for a read-only guide tool this is not a significant omission.

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 fairly long but each part earns its place: the purpose is front-loaded, the six options are compactly listed with explanations, and the final sentence gives routing advice. It could be slightly more concise, but the structure is logical and no information is redundant.

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 one enum parameter and no output schema, this description covers everything needed to call it correctly: what it does, what each option returns, and when to use it versus an alternative. No further details are required.

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

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

Schema description coverage is 0%, so the description must explain the single 'name' parameter. It does so thoroughly by enumerating all six enum values and giving a one-line explanation of each, which is exactly what an agent needs to select correctly. This fully compensates for the lack of 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 states a clear verb and resource: 'Return a curated, condensed guide bundled with this server.' It also lists all six available guide names with a short summary of each, making the tool's scope immediately obvious. It explicitly contrasts with avax_search_docs, distinguishing it from sibling tools.

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

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

Provides direct guidance: 'Prefer this for orientation, then avax_search_docs for details,' which tells the agent when to use this tool versus an alternative. Each guide description also implies a use case (e.g., troubleshooting for failures, gas-and-fees for fee config), so the agent can pick the right option.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond these, such as the specific receipt fields and supported network options (mainnet, fuji, L1 keys, full RPC URL). This enriches the behavioral understanding without contradicting any annotation.

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

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

The description is concise, with the core purpose stated first, followed by the network parameter details. Every sentence adds value; there is no filler. The structure front-loads the most critical information for an agent deciding whether to call the 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 simple read-only tool with only two parameters and no output schema, the description is nearly complete. It lists the inferred return fields and network options. It could mention potential edge cases (e.g., pending transactions or unavailable receipts), but these are inferred. Given the low complexity, the description suffices.

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%, and the schema already explains both 'hash' and 'network' in detail. The description repeats the network options but adds no new parameter-level meaning beyond what the schema provides. It does mention return fields, but those are not parameter semantics, so baseline 3 applies.

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 fetches a transaction and its receipt by hash, specifying exactly what information is returned (status, gas used, logs, contract address created). This is a specific verb+resource and distinguishes it from sibling tools like avax_get_block or avax_get_balance, which operate on different resources.

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 when to use this tool (to retrieve transaction details by hash) but provides no explicit comparison to alternatives or conditions for selecting it. For example, it does not mention that avax_get_block is for block data or that avax_get_balance is for account balances. The usage context is clear but not explicitly differentiated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable context beyond that: it is a network call to a specific endpoint (inducing potential rate limits), and it lists specific remote capabilities. It also notes the 'always-current' nature of docs_search, which is extra behavioral info. No contradiction with annotations.

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

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

The description is a single, tightly written paragraph. The core purpose is front-loaded, followed by a scoped use case list and a fallback rule. Every sentence carries meaning, with no filler. The structure makes it easy to scan and extract the essential decision logic.

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 proxy tool with only two parameters and no output schema, the description covers the key aspects: URL, when to use, specific tool examples, and rate-limit handling. It does not detail the return format, but given the open-ended nature of proxying (output varies by called tool), this is acceptable. The description could mention that the output is tool-specific, but the absence 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 coverage is 100%, so both parameters (name and arguments) are already documented. The description adds a critical semantic hint: 'pass chainId as a STRING' for build_plan, which clarifies a type requirement not present in the generic schema. It also gives examples of valid tool names, aiding correct invocation. This goes beyond the schema's generic 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 is a proxy to Ava Labs' hosted Avalanche MCP, with a specific verb ('proxy a tool call') and resource (the hosted MCP URL). It explicitly lists the tool names it is best for, distinguishing it from the many local sibling tools. This is unambiguous and immediately separable from alternatives.

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

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

Guidance is explicit: 'Best for things the local index lacks' and a concrete list of tools, plus a clear fallback instruction ('On 429 fall back to local tools'). This tells the agent exactly when to use this proxy versus local tools, and even provides a contingency for rate limits. It names alternatives implicitly by contrasting with 'local tools'.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint:false, so safety is covered. The description adds behavioral details beyond annotations: the rate limit of 60/min, the fixed set of ~48 tools, and the note that GitHub tools are not exposed. This enriches the agent's understanding without contradicting annotations.

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

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

The description is dense but structured: it leads with the primary purpose, then enumerates tool families, and ends with rate limit and preference guidance. It packs significant detail into a few sentences without redundant phrasing. While it lists many examples, each adds clarity about the tool's coverage, so it earns its place.

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

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

For a parameterless discovery tool with no output schema, the description is remarkably complete. It specifies the endpoint, the content (~48 tools with examples), rate limits, exclusions, and the recommended next step (avax_hosted_call). An agent has everything needed to decide whether to call this tool and interpret its result.

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 tool has zero parameters and the schema is 100% covered (empty schema), so the baseline is 4. The description doesn't need to explain parameters, and it doesn't attempt to. It focuses on the content and usage, which is appropriate for a parameterless tool.

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: 'List the ~48 tools exposed by Ava Labs' hosted MCP'. It provides a specific resource (the URL) and enumerates the tool families, distinguishing it from siblings like avax_hosted_call or avax_search_docs. The verb 'List' is specific and the scope is well-defined.

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

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

The description gives explicit usage context: it advises 'prefer local tools when equivalent' and directs the agent to 'Then call avax_hosted_call' after listing. It also clarifies scope exclusions ('GitHub code-search tools are documented but not currently exposed'). However, it doesn't explicitly state when to use this tool vs. specialized siblings beyond the general 'prefer local' guidance, so it's slightly incomplete.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it specifies the output format ('markdown link lists') and a freshness guarantee ('always current'). It does not mention auth requirements or rate limits, but for a simple read operation with strong annotations, this is sufficient. No contradiction with annotations.

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

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

The entire description is a single, dense sentence that front-loads the action, enumerates the exact valid inputs, and states the output format and freshness—all with zero filler. Every clause carries useful information, making it highly 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?

For a tool with a single enum parameter, strong read-only annotations, and no output schema, the description is complete. It tells the agent exactly what to expect (markdown link lists of every page), the valid inputs, and the freshness guarantee. There are no gaps in the required knowledge to call this tool correctly.

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 one parameter with an enum but zero description coverage. The description compensates by listing all allowed URI values and explaining what they represent (index resources that are markdown link lists). While it does not describe each URI individually, the names are self-explanatory (docs, academy, etc.) and the description clarifies the nature of the returned data. This adds meaning beyond the bare enum, even though schema coverage is 0%.

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 ('Read') and the resource ('one of the hosted MCP's index resources'), enumerates all seven valid URIs, and describes the output as 'markdown link lists of every page, always current.' This distinguishes it from sibling tools like avax_get_doc by specifying it returns a link list rather than a document. The purpose is unambiguous and action-oriented.

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 when to use the tool (when a full index of pages is needed) but does not explicitly mention alternatives or exclusions. It does not contrast with sibling tools like avax_get_doc or avax_search_docs, leaving the agent to infer that this is for list navigation rather than specific content retrieval. The 'always current' phrase hints at a freshness benefit, but there is no explicit 'use this when...' or 'instead of...' guidance.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, covering the safety and repeatability profile. The description adds that the tool returns structured recipe content (addresses, steps, skeleton, commands), which is output context beyond the annotations but not a distinct behavioral trait. It does not contradict the annotations.

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

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

The description is a single sentence that efficiently packs the deliverable into a list of concrete items. It is front-loaded with 'Return' and enumerates key outputs without verbose qualifiers, making it concise and scannable.

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?

The description covers what is returned but omits how parameters alter the recipe and when to use the tool. Given the tool's moderate complexity (3 optional params, no output schema) and weak schema coverage, more contextual guidance would be valuable, but the core output is specified, so it is not entirely deficient.

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 only 33% (source has a description; destination and payload_kind have none). The description does not explain any parameters, nor does it compensate for the low coverage by clarifying how source/destination or payload_kind affect the recipe. An agent would have to rely on defaults and enums without additional semantic context.

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 returns addresses, lookup steps, Solidity skeleton, and relayer commands for ICM messaging between two Avalanche chains. It specifies a concrete verb ('Return') and a precise resource (ICM/Teleporter integration recipe), which differentiates it from many sibling tools focused on queries or docs. However, it does not explicitly contrast with potentially overlapping tools like avax_get_guide or avax_search_docs, so it stops short of full differentiation.

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 gives no explicit guidance on when to use this tool versus alternatives. It does not state conditions such as 'use this when building ICM integrations' or 'for general guides, see avax_get_guide'. The intent is only implied by the tool's name and content, leaving the agent to infer appropriate usage without direct support.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds behavioral context by indicating the tool lists pages under a path prefix and is intended for browsing a table of contents. It does not describe return format or pagination, but given the annotations, this is acceptable.

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 a single concise sentence with the core action front-loaded, followed by useful examples and a usage hint. No redundant phrases or filler. It earns its place completely.

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

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

For a simple two-parameter listing tool with no output schema, the description conveys the essential purpose and provides concrete usage examples. It does not mention what the response contains (e.g., list of page paths or titles), but given the low complexity and existing annotations, this is a minor gap rather than a blocking one.

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 0%, so the description must document the parameters. It implies path_prefix through examples ('under a path prefix' with example paths) but never explicitly names the parameter or explains its format. The limit parameter is not mentioned at all. The description partially compensates but leaves the limit parameter semantically undocumented.

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

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

The description states the specific action 'List documentation pages under a path prefix' and provides concrete examples. It clearly distinguishes from siblings like avax_get_doc (fetch a single doc) and avax_search_docs (search) by defining the browsing/scoping behavior. The resource and action are specific and non-tautological.

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 gives a clear when-to-use hint: 'Use to browse a section's table of contents.' This contextualizes its role relative to other doc tools. It does not explicitly mention when not to use it or name alternatives like avax_list_topics, but the usage hint plus examples are reasonably sufficient for an agent to select it correctly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. The description adds context about what the output contains (chain IDs, RPC URLs, etc.), but this is more about the result content than behavioral characteristics. It does not add information about rate limits, authentication, or side effects beyond the read-only nature already annotated. With annotations covering the safety profile, a 3 is appropriate because the description provides some value but not rich behavioral context.

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

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

The description is two sentences with zero waste. The first sentence front-loads the core action and specific content, while the second sentence provides clear usage direction. Every word earns its place. It is appropriately sized for a simple, parameter-free enumeration 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 tool with no parameters, no output schema, and a simple enumerative purpose, the description is fairly complete. It tells the agent what networks are included, what fields are returned, and when to use it. It does not describe the exact output format (e.g., JSON structure), but with no output schema provided, some inference is acceptable. The phrase 'well-known L1s' could be slightly ambiguous, but the overall intent is clear. The description covers the essential information an agent needs to call it correctly.

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 tool has zero parameters, so the schema automatically covers them fully (100% coverage). Since there are no parameters to describe, the description does not need to add parameter semantics. The baseline for 0 parameters is 4 per the calibration guidance, and the description does not attempt to invent parameter information. It uses the 'network' value in the usage guidance, but that refers to the output values, not input parameters.

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

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

The description clearly states the tool's purpose: to list all networks known to the server, specifying the exact networks (Mainnet C-Chain, Fuji testnet, well-known L1s) and the information provided (chain IDs, RPC URLs, explorers, faucets). This is a specific verb (list) plus a specific resource (networks), and it distinguishes itself from sibling tools like avax_get_block or avax_get_balance which are data retrieval operations on specific networks rather than enumeration of available networks.

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 an explicit usage condition: 'Call this first when unsure which `network` value to use.' This tells the agent exactly when to invoke the tool. However, it does not explicitly state when not to use it or name alternatives, though the implied guidance is clear—if you already know the network, you don't need this. It could have mentioned that other network-dependent tools rely on the values returned here, but the core guidance is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint safely, lowering the bar. The description adds useful context beyond this: it discloses that the view reflects the *indexed* knowledge base and surfaces an index build date, signaling the data may lag live sources. This is meaningful behavioral context about 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?

Two sentences with zero redundancy. The resource and purpose are front-loaded in the first sentence, and the usage cue follows immediately in the second. Every word earns its place.

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

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

For a parameterless overview tool, this is complete: it explains what will be returned (sections, counts, build date) and when to use it. Safety and idempotency are covered by annotations, and there is no output schema to account for, so no return-format detail is missing.

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 tool has zero parameters, so the baseline is 4. There is nothing for the description to add in terms of parameter meaning, and the description correctly focuses on output and usage instead.

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 names a specific verb and resource ('Overview of the indexed Avalanche knowledge base') and details the exact output: top-level sections with document counts and the index build date. This is clearly distinct from search and doc-listing siblings, since it presents an orientation-level summary rather than individual documents.

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

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

The phrase 'Use to orient before searching' gives an explicit trigger condition and sequencing instruction, telling the agent to call this before running a search. It implies the alternative is the search family of tools, though it doesn't name a specific sibling or state explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral detail by naming the specific info.* endpoints contacted and the returned fields, which goes beyond the bare annotation. It does not contradict the annotations and aligns with the openWorldHint by mentioning the public API.

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

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

Two concise sentences, with the core endpoint and data list front-loaded and the use case immediately after. No fluff or repetition; every clause adds 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?

For a single-parameter, read-only tool with no output schema, the description covers the purpose, specific endpoints, returned data, and a use case. It does not explicitly state the return JSON format, but the listed fields strongly imply it, making it adequately 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?

The input schema fully covers the only parameter (network) with an enum, default, and description. The description only adds a tangential reference to 'which network you're on', offering no substantive new semantics beyond the schema. Baseline 3 is appropriate given 100% 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 states a specific action ('Query the public API node's info.* endpoints') and enumerates the exact data returned (node version, network ID/name, blockchain IDs, tx fees). This clearly differentiates it from sibling tools like avax_get_balance or avax_pchain_* which target specific data types.

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 notes it is 'Useful to confirm which network you're on and current P-Chain fees', providing clear contextual guidance for when to invoke it. It does not explicitly exclude alternatives or list when-not-to-use, but for a read-only info tool this is sufficient.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds behavioral context beyond annotations by breaking down the balance into three categories, which informs the agent about the expected output structure. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence that states the action, resource, and key details without any fluff. Every phrase earns its place, and the example address is a practical addition.

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 (2 parameters, no output schema) and annotations covering safety, the description is quite complete. It explains what the tool does, why it's needed, and hints at the return categories. It does not describe error handling or exact return format, but those are not essential for a read-only balance check.

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 both parameters are already documented. The description adds an example address format (P-fuji1...) and clarifies the address type, but does not significantly go beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the resource (P-Chain balance), the verb (get), and specifies the three balance components (unlocked, locked stakeable, locked not stakeable). It also gives a concrete address example, making it easy to distinguish from X-Chain or other balance tools among the siblings.

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

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

The description provides a clear use case: 'Needed before creating subnets/chains or adding validators.' This gives context for when to call the tool, but it does not explicitly name alternatives or state when not to use it (e.g., for X-Chain balance). Since the sibling set includes avax_xchain_get_balance, this is a minor gap.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the specific data fields returned (current supply, total stake, etc.), which goes beyond what annotations alone convey. No contradiction exists.

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

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

Two sentences, no fluff. The purpose and use-case are stated in the first sentence, and the usage guidance is in the second. Every word earns its place.

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

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

For a read-only query tool with a single well-documented parameter, the description is complete. It lists all the data categories returned, and the annotations cover the safety/profile aspects. No additional behavioral or syntactic details are needed.

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 only parameter, 'network', has a description in the schema ('Primary network: mainnet or fuji'), an enum, and a default. Schema description coverage is 100%, so the description adds no additional parameter meaning. This meets the baseline for fully documented parameters.

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

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

The description clearly states the tool returns P-Chain staking economics and enumerates specific data fields (min validator/delegator stake, min/max stake durations, current supply, total stake). It uses the verb 'Return' and the resource 'P-Chain staking economics', which distinguishes it from sibling tools like avax_pchain_get_validators (validator list) and avax_get_balance (balances).

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 gives use cases: 'Use when designing validator economics or answering "how much AVAX do I need to validate?"' This provides clear context for when to invoke the tool. It does not explicitly mention when not to use it or name alternatives, but the use-case framing is sufficient for an agent to route correctly.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate read-only behavior. It adds value by detailing what the response includes (control keys, threshold, isPermissioned status, manager chain/address, blockchains), giving the agent a clear expectation of the returned data. It does not disclose error behavior or pagination, but for a simple getter with annotations covering safety, this is above average.

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 a single, front-loaded sentence that states the core action first and then packs the specific data fields delivered. Every clause earns its place—no filler, no redundancy. The structure makes it easy for an agent to quickly parse the tool's purpose and outputs.

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?

With no output schema, the description compensates by listing the key return fields (control keys, threshold, isPermissioned, manager, blockchains), which is sufficient for an agent to know what it will get. It does not cover error scenarios or edge cases (e.g., subnet not found), but for a simple read-only getter with only two well-documented parameters, this is nearly complete. Missing details like response format are minor.

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%: both 'network' and 'subnet_id' have descriptive comments. The description does not add any parameter-specific meaning beyond the schema; it only lists what data is fetched. Since the schema already explains the parameters, the description adds no extra semantic value, matching the baseline of 3.

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

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

The description opens with a specific verb-resource pair ('Get Subnet details') and then enumerates the exact data fields returned (control keys, threshold, isPermissioned, manager, blockchains). It also names the underlying platform.getSubnet call, which unambiguously identifies the operation and naturally distinguishes it from sibling tools like get_validators or get_balance.

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 no guidance on when to use this tool versus its siblings. It does not mention alternatives, exclusions, or prerequisites (e.g., 'use list_blockchains first to get subnet_id'). The purpose implies it is for subnet-specific details, but no explicit when-to-use or when-not-to-use guidance is given.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description is not fully burdened. The description adds the detail about returning a reason when dropped, which is useful, but does not disclose rate limits, error handling, or other behavioral nuances. With annotations present, this is adequate but not exceptional.

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?

A single, tightly written sentence that first states the action, then the possible results, then the usage context. No wasted words, and the information is front-loaded with the purpose.

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

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

For a simple read-only tool with well-documented parameters and no output schema, the description covers the core need: what it returns (statuses, including drop reason) and when to use it. It is complete enough for an agent to call correctly, though it could optionally mention that 'Unknown' may mean a recently submitted transaction.

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 both tx_id and network are already documented. The description adds usage context that implies tx_id comes from the mentioned transaction types, but it does not add format or additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool checks a P-Chain transaction status with specific possible values (Committed, Processing, Dropped, Unknown) and includes the underlying API (platform.getTxStatus). It distinguishes itself from siblings like avax_get_transaction or avax_get_chain_status by focusing on P-Chain transaction status with explicit status outcomes.

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

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

It explicitly says 'Use after AddSubnetValidator/ConvertSubnetToL1/CreateChain transactions', giving clear context on when to invoke this tool. However, it does not mention when not to use it or point to alternative tools for other chain transactions, so it lacks explicit exclusions or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by listing the returned fields (nodeID, stake, uptime, end time, delegation fee) and naming the exact RPC method. It does not disclose pagination details or response formatting, but given the annotations cover the critical behavioral aspects, this is adequate.

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

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

Two sentences with no filler. The first sentence states the complete purpose including the RPC method and returned fields. The second sentence gives the key usage distinction between subnet and primary network. Every word earns its place.

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

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

For a read-only, idempotent list operation with no output schema, the description covers the main functional aspects: scope selection and return contents. It does not mention pagination or that limit controls the number of results, but limit is already described in the schema. The method name and return fields provide enough context for an agent to call it correctly.

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% (limit lacks a description, others have one). The description adds meaning for subnet_id by explaining that omitting it means Primary Network and including it inspects an L1 set. It does not elaborate on limit, node_ids, or network beyond what the schema provides. Since coverage is high and the description adds one useful clarification, it meets the baseline 3 without exceeding it.

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

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

The description states a specific verb (List), the resource (current validators), and two clear scopes (Primary Network or a specific Subnet/L1). It also names the underlying API method, which removes ambiguity. While it doesn't name a sibling tool explicitly, it clearly differentiates the Primary Network case from the subnet case, which is the main usage distinction.

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 gives explicit guidance on when to include subnet_id (to inspect an L1's validator set) and when to omit it (Primary Network). This is a clear usage condition. However, it does not compare against sibling tools like avax_pchain_get_stake_info or avax_data_list_l1_validators, so an agent might not know when to prefer this over those. Still, the subnet guidance is concrete and actionable.

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

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

Annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context about the return content (subnet and VM IDs) and the availability of filtering and pagination, which goes beyond the annotations without contradicting them.

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

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

Two short sentences, front-loaded with the main action, and every phrase earns its place. No redundancy or filler.

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

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

The description covers the essential behavior and return info (subnet and VM IDs) for a list operation. Since there is no output schema, the mention of return fields is helpful. Network default is documented in the schema, so it does not need repetition. Overall it is adequate for correct invocation, though it could hint at pagination constraints or network selection.

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 schema description coverage at 50%, the description does compensate partially by mentioning 'name filtering' (mapping to name_contains) and 'pagination' (mapping to limit/offset). However, it does not explain the network parameter or elaborate on the specific semantics of parameters beyond what the schema already provides for network and name_contains.

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

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

The description states a clear verb and resource: 'List all blockchains registered on the P-Chain' with specific details about the output (subnet and VM IDs). It is specific enough to distinguish from sibling tools like avax_pchain_get_subnet, which focuses on individual subnet data.

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 its use case (listing blockchains) and mentions supports for filtering and pagination, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling differentiation is provided, leaving the agent to infer based on names.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the plan's content (consensus, validators, ICM, cost, CLI commands) but does not disclose any additional behavioral traits beyond that. It does not contradict the annotations.

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

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

The description is a single, well-structured sentence that front-loads the primary purpose and lists the plan's deliverables. It wastes no words, efficiently conveying scope and sequencing without unnecessary elaboration.

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 planning tool that is read-only and idempotent, the description covers the core input (use_case) and output expectations (plan contents). It does not specify the output format or error handling, but those are not critical given the annotations and the lack of an output schema. The explicit sequencing with avax_generate_genesis strengthens completeness for the intended workflow.

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 only 40%, so the description should compensate by explaining each parameter. It does not explicitly map parameters like target, needs_icm, validators, or permissioned to their meaning. It hints at permissioned via 'consensus mode (PoA/PoS)' and mentions validator count, but the description focuses on the output content rather than input semantics, leaving the agent to rely on the sparse 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 states a specific action ('Produce a tailored, step-by-step launch plan') with a clear resource (a new Avalanche L1) and enumerates the key components (consensus mode, validator count, gas/token choices, precompile recommendations, ICM, cost estimate, CLI commands). It also differentiates itself from the sibling avax_generate_genesis by explicitly positioning itself as a precursor step, making its purpose unmistakable.

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 instructs 'Use before avax_generate_genesis,' providing clear sequential context. However, it does not mention when to avoid using the tool or name alternative planning-related siblings (e.g., avax_icm_recipe, avax_explain_precompile), so the guidance is not fully exhaustive.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral detail: it returns 'ranked snippets with title, heading, url and path' and explains that it is a search (not a full-text retrieval) with a follow-up call to avax_get_doc. It also mentions the default limit and source filter behavior, which goes beyond annotations. No contradiction found.

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 detailed but efficiently structured: an opening purpose sentence, a usage guideline, and a bulleted argument list with examples. It avoids redundancy and keeps each sentence informative. It is slightly long, but the density of information justifies the length. The layout makes key points scannable.

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 no output schema, the description covers all essential aspects: the scope of sources, when to use it, what each parameter does, and the expected return (ranked snippets with metadata). It also closes the loop by directing the agent to avax_get_doc for full content. There is no critical missing information that an agent would need to call the tool correctly.

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 0%, so the description carries the full burden of parameter explanation. It thoroughly details each argument: query with natural-language examples, source with an enumerated list and descriptions (e.g., 'integrations (234 ecosystem integrations: oracles, bridges, indexers, wallets, RPC providers…)'), path_prefix with concrete examples, and limit with its default and range. This adds significant meaning beyond the raw schema types.

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 it is a 'Full-text search over the official Avalanche knowledge base' and enumerates the specific sources (docs, Academy, integrations, etc.). It also frames its role as the first-stop for 'how do I…' and 'which precompile/config/command…' questions, distinguishing it from other tools like avax_get_doc or avax_list_docs. The verb ('search') and resource ('Avalanche knowledge base') are explicit, and the scope is narrowed with a clear boundary.

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 instructs 'Use this FIRST for any…' and lists example question types, providing clear when-to-use guidance. It also points to avax_get_doc as the follow-up for reading full pages, which gives a workflow. However, it does not explicitly state when NOT to use this tool (e.g., when a more specialized search like avax_search_integrations would be better), so it falls just short of 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?

Annotations already establish read-only/idempotent behavior, and the description adds valuable context beyond them: the dataset is offline, contains 234 entries, and returns name, category, chains, and links. It does not explain matching behavior, but the key traits are well covered.

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 one dense, front-loaded sentence with no wasted words. The enumerated categories, offline flag, entry count, and return fields all earn their place and improve usability.

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

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

For a simple closed-world search tool with no output schema, the description covers the dataset's source, size, offline nature, search dimensions, and returned fields. It is only slightly incomplete in not steering users toward sibling tools and not listing the full category taxonomy.

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 0% schema description coverage, the description must compensate. It tells the agent that queries can be keywords or categories and lists output fields, but it does not clarify that category is expressed through the query string rather than a separate parameter, nor does it explain the limit parameter semantics beyond the schema's defaults.

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 names a specific verb and resource: 'Find Avalanche ecosystem integrations,' and adds concrete scope with 234 entries and example categories. This clearly differentiates it from sibling search tools like avax_search_docs or on-chain data tools.

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?

Usage is implied: use this when searching ecosystem integrations by keyword or category. However, there are no explicit when-to-use or when-not-to-use statements, nor any named alternatives despite the large sibling tool list.

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

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

The description is consistent with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) and adds that the tool returns diagnosis and documentation references. It does not disclose any additional behaviors such as rate limits, source dependencies, or depth of analysis, but given the annotations already cover safety, a middle score is appropriate.

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?

A single, well-structured sentence that front-loads the core behavior and specifies input categories. No wasted words; every clause adds relevant 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 a simple tool with one required parameter and no output schema, the description sufficiently covers input types and expected return (causes, fixes, documentation). It does not mention potential limitations (e.g., unsupported error types) but is complete for typical use, especially with the schema filling in parameter constraints.

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

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

Schema coverage is 50%: the 'context' parameter has a descriptive schema but 'error_text' does not. The tool description adds meaning to 'error_text' by clarifying it is an error message or symptom with categories, which helps the agent. However, it does not elaborate on how 'context' affects the analysis beyond the schema's example, so it only partially compensates for the 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 a specific verb and resource: given an error message or symptom (RPC error, CLI output, revert reason, ICM delivery issue), return likely causes, fixes, and matching documentation. It distinguishes itself from generic doc-search siblings by focusing on troubleshooting an error, though it doesn't explicitly name an alternative.

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

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

The description clearly implies when to use this tool—when you have an error message or symptom—and what it will return. However, it does not explicitly state when not to use it or point to alternatives like avax_search_docs for general documentation lookup, leaving that inference to the 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context about the query mechanism (omitting vs passing a value) and the structured nature of the return. It does not contradict annotations and provides useful additional operational detail, though it omits edge-case behavior like invalid inputs or result limits.

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 a single, well-structured sentence that front-loads the key resource and fields, then provides query instructions and sibling references. Every segment earns its place with concrete examples; there is no redundancy or unnecessary filler.

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

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

For a tool with one optional parameter and no output schema, the description covers what it returns (structured history with listed fields), how to tailor the query, and where to find complementary details (siblings). Given the low complexity and annotation coverage, nothing essential is missing for correct invocation.

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

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

With 0% schema coverage and a single undocumented parameter, the description fully compensates by specifying accepted formats and examples (e.g., 'Helicon', 'v1.14.0', 'ACP-194') and the default behavior when omitted. This gives the agent precise, actionable semantics for the `query` parameter, exceeding the bare 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 returns a structured history of Avalanche Primary Network upgrades, listing specific fields (name, version, dates, status, chains, ACPs, impact, docs). It also differentiates from siblings by naming paired tools (avax_acp_lookup, avax_get_doc) and explicitly explains how to query by name, version, or ACP. This leaves no ambiguity about what the tool does.

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 instructions: omit `query` for the full timeline, or pass an upgrade name, version, or ACP number for a single entry. It also recommends pairing with related tools for full detail, guiding the agent on when to use this tool versus alternatives. No inference is required.

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

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

Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully carried by structured data. The description adds modest value by naming the underlying API call (avm.getBalance) and the multi-asset capability, but nothing further about behavior (e.g., balance format, zero-balance handling).

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?

A single, front-loaded sentence with zero filler. The core purpose is stated up front and the underlying API reference is appended compactly; nothing could be trimmed without losing meaning.

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

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

For a simple read-only balance tool with full parameter schema coverage and annotations covering the safety profile, this is nearly adequate. The main missing element is usage routing to sibling balance tools (avax_get_balance, avax_pchain_get_balance), which matters given the sibling set.

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

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

Schema coverage is 100%: all three parameters (address, network, asset_id) are documented with descriptions. The description echoes the asset flexibility (AVAX or any asset) that maps to asset_id but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get X-Chain balance for an X-addr') and clarifies the asset scope ('AVAX or any asset'). The X-Chain qualifier implicitly distinguishes it from avax_get_balance and avax_pchain_get_balance, though it doesn't name siblings explicitly.

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

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

No guidance on when to use this tool versus the generic avax_get_balance or the P-chain variant avax_pchain_get_balance. No exclusions or prerequisites are given; selection context is only implicit via the X-Chain qualifier in the name and title.

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