Explain a Subnet-EVM precompile

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.