Name Whisper — ENS Intelligence Layer

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

With no annotations, the description fully explains the atomic transactions (WETH pull, ENS transfer, fee payment) and potential revert conditions. It also clarifies the output is unsigned calldata, not immediate execution.

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 at ~150 words, front-loaded with the core purpose, and structured logically: action, atomic steps, prerequisites. Every sentence 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?

Given no output schema, it explains the return value (unsigned calldata) and side effects thoroughly. Could include more detail on calldata format or links, but is complete for agent understanding.

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

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

Schema description coverage is 100%, so the schema already defines both parameters. The description reuses parameter names but adds context (e.g., wallet must own the name). No new semantic depth 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 clearly states the tool accepts a standing offer on an ENS name and returns unsigned Seaport calldata. It distinguishes itself from sibling tools like make_offer or cancel_offer by focusing on the acceptance action.

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

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

Provides explicit prerequisites (approval via approve_operator) and suggests using get_name_details to verify offers. Lacks an explicit 'when not to use' but covers context and alternatives well.

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

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

With no annotations provided, the description fully discloses behavioral traits: it explains that approval covers all tokens, describes each contract's token type, gives the underlying method (setApprovalForAll), and includes a security warning about approval drain attacks. This is comprehensive and transparent.

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 and well-structured: opening sentence, explanation of functionality, contract list with token types, common use cases, contract addresses, and a warning. Every sentence adds value, and the most critical information is front-loaded.

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 all necessary context: the action (approve/revoke), scope (all tokens), contracts involved, use cases, contract addresses, and a security warning. Given no output schema, it sufficiently informs the agent of the tool's effects and risks.

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, and the description adds context by explaining that the approval is setApprovalForAll and covers all tokens. However, it does not add new parameter-level syntax beyond what the schema provides (e.g., operator is an address, approved is a boolean). The baseline is 3, and the description meets it with minor added 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's purpose: 'Approve or revoke an operator for ENS contract interactions.' It specifies that it is setApprovalForAll covering all tokens, not just one, and lists the three specific contracts. This distinguishes it from sibling tools like manage_ens_name or set_ens_records.

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 common use cases (e.g., approve before wrapping, approve marketplace) and a warning to only trust verified addresses. It implicitly guides when to use the tool but does not explicitly mention when not to use it or compare with alternatives. The guidance is helpful but not 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?

No annotations exist, so the description carries full burden. It discloses: returns unsigned Seaport orders, requires EIP-712 signing and subsequent submission, per-name error handling with partial success, and operator approval prerequisite. This is thorough, though rate limits or idempotency are not mentioned.

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 six sentences, each adding essential information. It front-loads the main action and avoids redundancy. Every sentence earns its place.

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

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

Given the tool's complexity (batch signing, external submission, prerequisites, partial success), the description covers all critical steps and edge cases. Without an output schema, it sufficiently describes what the agent must do next.

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%, baseline 3. The description adds context beyond schema by explaining the batch error handling for listings, the wallet ownership requirement, and the default duration. This extra meaning justifies a 4.

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 bulk-lists up to 10 ENS names for sale, with a specific verb ('bulk-list') and resource ('ENS names on NameWhisper'). It distinguishes from the sibling create_listing by mentioning one wallet popup vs N.

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 when to use this tool (multiple listings in one flow, cheaper UX) and outlines the required post-signing steps. It implies create_listing for single listings, but does not explicitly state when not to use it. Also notes NW-native restriction.

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

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

No annotations provided, so the description fully explains behavior: it picks the cheapest listing, loads Seaport orders, packs them into one transaction, handles partial fills (skips sold/cancelled, refunds excess), and returns both successful and failed items. Gas savings are also mentioned.

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 somewhat long but well-structured. It front-loads the core purpose and usage guideline, then details mechanics and failure handling. Every sentence adds value, though a slight trim could improve conciseness.

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

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

No output schema, but description explains the response format (lists bought with marketplace+price, lists failed). With only two parameters and clear behavior, the description covers all necessary context for an agent to use 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 coverage is 100% with descriptions for both parameters. The description adds useful context beyond schema: 'names' max 20 per batch, 'walletAddress' receives all purchased names. This enhances understanding without being redundant.

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 buys up to 20 specific ENS names in a single Seaport transaction from NameWhisper, OpenSea, and Grails. It distinguishes itself from sibling tools like 'sweep' (floor sweep) and 'purchase_name' (single name), making the purpose unambiguous.

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

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

Explicitly states when to use this tool ('when the user names the exact names to buy') and when to use alternatives ('sweep' for floor sweep, 'purchase_name' for single names or failed listings). Provides clear decision criteria.

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

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

With no annotations provided, the description carries full disclosure responsibility. It transparently explains the two-step transaction process, the 60-second wait, ETH refund mechanics, shared secret, and availability requirement. This provides sufficient insight into the tool's behavior beyond basic idempotency or side effects.

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

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

The description is well-organized with three concise paragraphs: first introduces the main action and benefit, second details the process, third adds constraints and follow-up. Every sentence contributes meaning, though the material could be slightly tightened without losing clarity.

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

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

Given the tool's complexity (multi-step, batch constraints, refunds), the description covers the essential behavioral aspects including the waiting period, refund logic, and requirement that all names be available. It also points to a sibling tool for post-registration configuration. While not exhaustive (e.g., missing error conditions), it provides enough context for correct use.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by clarifying that duration applies to all names, that durationYears is deprecated, and that names must be registered in array form. However, it doesn't significantly augment the schema; the added process context is useful but does not deepen parameter understanding.

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 registers multiple ENS names in bulk using a two-transaction process (multiCommit + multiRegister). It distinguishes this from single-name registration by highlighting cost and speed benefits, and effectively differentiates from sibling tools like bulk_set_records.

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 outlines the use case: registering up to 20 names at once more cheaply and quickly than individually. It details the required flow (commit, wait, register) and mentions post-registration next steps (use bulk_set_records). While it doesn't explicitly contrast with alternatives like purchase_name for single registrations, the context is clear enough for an agent to decide when to invoke this tool.

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

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

With no annotations provided, the description carries the full burden effectively. It discloses the batching mechanism ('resolver.multicall()'), cost efficiency, ownership requirements, and the 50-name limit. It lacks details on atomicity (whether partial failures are possible) and does not describe the return value.

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?

Five well-structured sentences with zero redundancy. Information is front-loaded with purpose, followed by technical mechanism, capabilities, usage patterns, and constraints. Every sentence earns its place.

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

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

Given the high complexity of bulk ENS mutations and absence of annotations/output schema, the description comprehensively covers operational mechanics, authorization rules, and limits. The only gap is the lack of description for what the tool returns (e.g., transaction hash).

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

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

Although schema coverage is 100%, the description adds significant semantic value by providing concrete examples of record types ('ETH, BTC, SOL', 'avatar, description') and explaining usage patterns ('different records for each name... or the same records across all names'), which helps the agent understand how to populate the nested nameRecords structure.

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 ('Set'), clear resource ('ENS resolver records'), and distinct scope ('multiple names in a single transaction — bulk record editing'). It explicitly references sibling tool set_ens_records to differentiate the bulk vs. single-name use case.

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 clear context for when to use (bulk operations are 'Much cheaper than setting records one name at a time') and references the alternative tool set_ens_records. It states the 50-name limit and ownership prerequisites. However, it does not explicitly state when NOT to use it (e.g., 'do not use for single 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?

With no annotations, the description fully discloses behavioral traits: automatic detection of wrapped/unwrapped names, transfer ownership implications, unaffected resolver records, and a suggestion for post-transfer action. This provides clear guidance on what to expect.

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

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

The description is well-structured: starts with a clear purpose, then benefits, technical details, requirements, a warning, and a follow-up suggestion. It is appropriately sized for the complexity, with no redundant sentences.

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

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

Given no output schema, the description covers all necessary contextual information: what happens (ownership transfer), prerequisites, constraints (max 20, min 1), and a post-transfer recommendation. It is complete for an agent to understand usage.

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%, but the description adds meaning by explaining that 'toAddress' can be an ENS name resolved automatically, and that 'transfers' array has items with specific fields. It also clarifies the ownership requirement for 'fromAddress'.

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 'transfer', resource 'multiple ENS names', and method 'in a single transaction via Multicall3'. It directly distinguishes from the sibling tool 'transfer_ens_name' by emphasizing bulk operation.

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 when to use (cheaper and faster than single transfers) and lists requirements (ownership of all names, valid addresses, registered names). It implicitly suggests not using for single transfers. While no explicit 'when not to use', the context 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?

Discloses that it returns unsigned calldata, requires signing and submission, marks order invalid, and that only original seller can cancel. Also explains atomic cancellation with alsoCancel.

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?

Well-structured and concise. Each sentence adds value, front-loading the main action and then providing necessary details.

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 explanation given the tool's complexity: describes return type, process, edge case of cross-posting, and no reliance on output schema.

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

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

Schema coverage is 100%, and description adds extra context for alsoCancel (sibling hashes) and walletAddress (must match offerer), going beyond schema descriptions.

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

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

The description clearly states it cancels an active ENS name listing via Seaport's cancel() and distinguishes from cancel_offer by specifying that offers are for buyers.

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 (cancel active listing), who can use (original seller), and how to handle cross-posting (pass both order hashes). Alternative tool cancel_offer is mentioned.

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

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

The description discloses that cancelling releases committed WETH, returns unsigned Seaport calldata, and that cancelling N orders costs little extra. With no annotations, this carries the burden well, though it could mention error cases or effects on expired offers.

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 four sentences, front-loaded with the main action, and each sentence adds distinct value. There is no redundant or unnecessary content.

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 core behavior and financial impact, but it does not explain how to handle the returned calldata or what happens on invalid or expired orders. Given no output schema, this omission affects completeness.

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

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

The input schema has 100% coverage, and the description adds context: orderHash source, alsoCancel usage for OpenSea variants, and walletAddress as the bidder's wallet. This adds meaning beyond the schema patterns.

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

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

The description explicitly states it cancels an active offer on an ENS name, using specific verbs and resources. It also distinguishes from the sibling tool cancel_listing by stating 'For cancelling your own listings, use cancel_listing.'

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 who can cancel (only the bidder/offerer), when to use alsoCancel for OpenSea cross-posts, and directs users to cancel_listing for listings. It provides explicit context for when to use this tool versus alternatives.

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

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

No annotations, but description adds important behavioral info: validates ENS character rules, explains GRACE_PERIOD behavior (not registerable), and confirms suffix flexibility. Discloses scope and constraints.

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

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

Extremely concise: four sentences covering purpose, output format, behavioral nuance, and flexibility. Front-loaded with key action. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description is fully complete. It explains output structure, edge cases (GRACE_PERIOD), validation, and input variations.

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

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

Schema has 100% coverage with a clear parameter description. Tool description adds extra detail: 'Accepts names with or without .eth suffix', which is not in 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?

Specifies verb 'Check availability' and resource 'ENS names'. Clearly states output with status types and additional data. Differentiates from siblings by being the specific availability checker.

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

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

Implies use case: when checking if a name can be registered. Does not explicitly state when not to use or list alternatives, but context is clear given sibling tools.

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

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

Despite no annotations, the description fully discloses behavior: returns unsigned Seaport OrderComponents, fee structure (1% marketplace fee), requirement for operator approval, and NW-native exclusivity. No contradictions.

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

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

The description is well-structured but slightly long. It front-loads purpose, then process, fee, exclusivity, prerequisites, and tips. Every sentence adds value, but could be condensed slightly without losing clarity.

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

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

Given the complexity of the tool, the description covers purpose, return value, follow-up actions (sign and submit), fee structure, exclusivity, prerequisites, and helpful tips. No output schema exists, but the return type is explained.

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 descriptions for all parameters. The description adds context: wallet must own the name, seller receives price minus fee, default duration 30 days, and the tip to use get_valuation and get_name_details.

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 starts with a specific verb+resource: 'List an ENS name for sale on NameWhisper's marketplace via Seaport 1.6.' It clearly distinguishes from siblings like cancel_listing, accept_offer, and batch_create_listings.

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

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

The description explicitly states when to use this tool (listing on NameWhisper), when not (NW-native only; for OpenSea use their interface), prerequisites (approve operator), and tips to use get_valuation and get_name_details.

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

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

Describes that it generates verified, correctly-spelled labels and returns entries grouped by status with proper names and ENS labels. With no annotations, it adequately discloses behavior, though lacks info on side effects or permissions.

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

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

Well-structured with USE THIS, DO NOT USE, and Returns sections. Every sentence adds value, but slightly verbose; could be trimmed for conciseness.

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

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

Given no output schema, the description thoroughly covers return format. It provides complete guidance for tool use, including parameter semantics and edge cases, making it highly informative.

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?

Despite full schema coverage (baseline 3), the description adds significant value by explaining filter options and providing detailed guidance on category parameter, including what to strip (availability, quality words).

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 enumerates ENS-friendly labels for real-world entity categories and reports availability. It distinguishes itself from siblings like search_ens_names and check_availability by specifying its unique use case.

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 provides when-to-use examples ('find me NBA hall of famers') and when-not-to-use scenarios (vibes/themes, ENS-native categories, single-name lookups). Also explains why not to use own context due to misspelling risks.

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

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

With no annotations provided, the description carries the full burden and successfully discloses critical behavioral constraints: the parent expiry ceiling, NameWrapper context, and the CAN_EXTEND_EXPIRY fuse requirement. It implies state mutation through 'burned' fuse terminology, though it could explicitly state this is a write operation or mention reversibility.

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?

Well-structured with clear sections (purpose, constraints, authorization, use cases). Slightly redundant with 'This tool extends a subname's expiry' restating the opening sentence, but overall efficient with no extraneous content. The bullet points earn their place by clarifying complex authorization 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?

Given the complexity of ENS fuses and NameWrapper logic, the description adequately covers authorization and domain constraints. However, with no output schema provided, it should ideally describe the return value (transaction hash, success boolean) or failure modes, which are absent.

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?

Input schema has 100% coverage with clear descriptions ('Full subname to extend', 'Number of years to extend'). The description reinforces the parent expiry constraint but adds no additional parameter semantics (format examples, validation edge cases) beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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

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

The description opens with a precise action ('Extend the expiry') and resource ('ENS subname in the NameWrapper'), distinguishing it from sibling tools like renew_ens_name (which handles parent names) and mint_subnames (which creates new ones). The specificity of 'NameWrapper' and 'subname' provides exact technical scope.

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

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

Provides explicit authorization rules ('Who can call this') detailing parent owner vs subname owner permissions with fuse requirements, and lists concrete use cases. However, it lacks explicit comparison to siblings (e.g., when to use this versus renew_ens_name for parent names), preventing a perfect score.

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

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

Despite no annotations, the description richly discloses behavior: uses same engine as get_valuation, cache-first, conservative (seller-wallet boost off), only real comparable matches, floors confidence at MEDIUM, and warns not to inflate values. No contradictions.

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 somewhat lengthy but well-structured: purpose first, then methodology, usage guidelines, and parameter details. Every sentence adds value, though some repetition could be trimmed. Front-loaded with clear 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 complex tool with 7 parameters and no output schema, the description covers return format (discount %, fair-value range, confidence, comparable data), selection algorithm, edge cases (fewer results than asked), and parameter details. Fully adequate for an agent to invoke correctly.

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

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

Schema coverage is 100%, so baseline 3. The description adds value by clarifying minConfidence floored at MEDIUM (LOW never returned), minDiscountPct default 20%, and the meaning of estimatedValueEth.mid. This extra context justifies a 4.

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 scans the ENS marketplace for undervalued names ('alpha'), using specific verb 'Scan' and resource 'ENS marketplace'. It distinguishes from siblings like search_ens_names + get_valuation by explicitly saying to use this instead for ranked-by-value queries.

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 this tool: 'Use this instead of search_ens_names + repeated get_valuation when the user asks for "best value", "best buy", etc.' Also advises not to call get_valuation again, and how to handle insufficient results.

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

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

With no annotations, the description carries the full burden. It discloses behavioral traits such as reading text records, resolving against registries, and the Sybil-ability of reputation scores. It provides good insight into how data is retrieved and its reliability, though it omits error handling or rate 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 detailed but compact, with the main purpose stated upfront. It uses bullet-point-like structure for return values, enhancing readability. A minor improvement would be further trimming redundant phrases, but overall it is well-organized.

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

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

Given no output schema, the description thoroughly explains return values: ENSIP-25 verification, metadata, ERC-8004 data, and ERC-8217 status. It also covers the reputation model's limitations. Missing error handling or pagination details, but for a simple lookup tool, it is sufficiently 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 100% coverage, describing the single parameter adequately. The description does not add extra meaning beyond stating the purpose; it neither deepens param understanding nor introduces new constraints. 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?

Description clearly states the tool checks if an ENS name or wallet is a registered AI agent and returns specific verification and reputation data. It explicitly distinguishes itself from siblings by detailing ENSIP-25, ERC-8004, and ERC-8217 aspects, which are unique to this tool.

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 what the tool does but does not explicitly state when to use it over sibling tools like 'register_agent' or 'search_agent_directory'. It lacks 'when not to use' guidance, leaving the agent to infer context from the detailed functionality.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses authentication requirements ('ERC-8128 signed requests') and return behavior ('resolves your wallet address to your ENS name...'). Minor gap: doesn't explicitly state idempotency or rate limiting, though 'Returns' implies read-only safety.

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, zero waste. Front-loaded with core purpose ('Returns...'), followed by conditional behavior details, ending with usage guideline and auth requirement. Every sentence adds unique value beyond the structured fields.

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

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

No output schema exists, so description must explain return values—it successfully does ('ENS name, agent metadata, and portfolio summary'). Covers critical auth context. Minor gap: doesn't describe error states (e.g., what happens if identity unrecognized).

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

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

Zero parameters with 100% schema coverage warrants baseline 4 per rubric. Description correctly focuses on auth requirements and return semantics rather than inventing parameter documentation where none exists.

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?

Excellent specificity: 'Returns the authenticated identity of the calling agent' uses clear verb+resource. Distinguishes from siblings like get_name_details (arbitrary names) and get_wallet_portfolio (just portfolio) by focusing on the caller's full identity resolution including ENS name, metadata, and portfolio.

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?

Explicit guidance: 'Call this first to confirm your identity is recognized' establishes clear invocation order. Prerequisites are clearly stated ('Requires ERC-8128 authentication') with reference to setup alternative ('See GET /mcp/auth'). Conditional usage is specified ('If you connected with ERC-8128 signed requests...').

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

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

With no annotations provided, the description carries full disclosure burden. It successfully explains sorting behavior ('Sorted by most recent first') and compensates for the missing output schema by detailing return fields (name, price in ETH, addresses, timestamp). It does not disclose rate limits or error behaviors, preventing a perfect score.

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

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

Four efficient sentences with zero waste. The description is front-loaded with the core action, followed by filter capability, return payload details, and sorting behavior. Every clause conveys unique information beyond what structured fields provide.

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 simple 3-parameter schema and lack of output schema or annotations, the description adequately covers the critical gaps by explaining the return structure and sort order. It appropriately omits parameter syntax details (covered by schema) but could marginally improve by noting all parameters are optional.

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?

While schema coverage is 100% (baseline 3), the description adds value by mapping the abstract 'eventTypes' enum to concrete business concepts (sales, new listings, renewals, burns). It also implies the temporal nature of the query ('recent'), providing semantic context for the limit/offset pagination parameters not explicitly detailed in the schema descriptions.

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

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

The description opens with a specific verb ('Get') and clearly identifies the resource ('ENS marketplace activity'). It enumerates specific event types (sales, listings, mints, etc.) that clearly distinguish this tool from siblings like get_name_details or get_wallet_portfolio, which retrieve static data rather than transactional event streams.

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 through the enumeration of marketplace events (sales, offers, burns), suggesting it's for monitoring market trends. However, it lacks explicit guidance on when to use this versus alternatives like get_name_details (for static lookups) or search_ens_names, and omits prerequisites or filtering recommendations beyond mentioning the capability exists.

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

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

With no annotations, the description fully discloses behavior: creationDate is always populated, with a special handling for Vickrey-era names explaining how dates are sourced. It also mentions resolver address and isPublicResolver flag. No destructive or hidden behaviors are omitted.

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

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

The description is detailed but front-loaded with key fields, then explains special behaviors for creationDate and resolver. It is slightly verbose but every sentence provides useful guidance. Could be marginally tightened, but overall well-structured.

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

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

Despite having no output schema, the description enumerates all returned fields and their nuances, making the tool's behavior fully understandable. It tells the agent exactly what to expect, compensating for the lack of an output schema.

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

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

The schema already documents the single parameter 'name' with 100% coverage, describing it as 'ENS name or label (e.g. "vitalik" or "vitalik.eth")'. The description repeats this example but adds no additional semantics 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 tool retrieves full details for an ENS name, listing specific fields like owner, expiry, creation date, tags, listings, offers, and identity bindings. It distinguishes itself from sibling tools by providing a comprehensive set of details not available elsewhere.

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?

Explicit guidance is given: 'Always mention creationDate when answering questions about when a name was created or registered' and 'use these to answer resolver questions instead of guessing; bulk_set_records works for any name where isPublicResolver is true.' This tells the agent when and how to use the tool and its returned fields.

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

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

With no annotations provided, the description carries full burden and excels by explaining the bidirectional validation logic ('verifies both directions'), the exact return values ('ENS name... or null'), and failure conditions ('If either direction is missing, the primary name won't resolve'). This critical ENS-specific behavior is not inferable from the schema alone.

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

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

The description is front-loaded with the core purpose in the first sentence. While lengthy, the detailed explanation of bidirectional resolution is essential context for ENS operations. The bullet points for use cases are structured and scannable, though the text could be slightly tightened 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?

Despite lacking an output schema, the description explicitly states what gets returned (the ENS name or null) and explains the validation logic required for successful resolution. For a single-parameter lookup tool, it provides comprehensive context covering success cases, failure modes, and debugging scenarios.

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 the walletAddress parameter already documented as 'Ethereum wallet address (0x...) to check reverse resolution for'. The description references 'wallet address' in the opening sentence but does not add significant semantic detail beyond what the schema provides, meeting the baseline for high-coverage schemas.

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

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

The description opens with a specific verb ('Check') and clearly identifies the resource ('primary ENS name') and operation ('reverse resolution'). It distinguishes itself from sibling tools like set_primary_name (the write counterpart) and search_ens_names (general lookup) by specifying this is specifically for reverse address-to-name resolution.

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 'Use this to:' followed by three concrete scenarios including post-operation verification ('after set_primary_name'), existence checks, and debugging. This creates clear workflow guidance relative to the sibling set_primary_name tool and indicates when the tool is appropriate versus when troubleshooting 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?

With no annotations, the description carries full burden. It discloses the use of vector embeddings across 3.6M+ names, the return of similarity scores and statuses, and the important constraint that GRACE_PERIOD names are not registerable by others. This provides good behavioral context beyond a simple search, though it does not cover potential rate limits or auth needs.

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 core purpose. Every sentence adds essential information: first sentence defines what the tool does, second sentence details the output and an important constraint. No unnecessary words.

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

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

Despite no output schema, the description adequately describes the return format (similar names with scores, statuses, marketplace data) and the critical nuance about GRACE_PERIOD names. For a tool with only two parameters and full schema coverage, this provides sufficient context for an agent to use 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 100%, but the description adds significant value: it provides an example for the name parameter ('coffee', 'pixel.eth'), and clarifies the default (20) and maximum (50) for limit. This enriches the schema descriptions and helps the agent use parameters correctly.

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 finds ENS names semantically similar to a given name using vector embeddings across 3.6M+ names. It specifies the verb 'Find', the resource 'ENS names', and the method 'vector embeddings'. This distinguishes it from siblings like search_ens_names (exact or keyword) and check_availability (availability check).

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

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

The description implies usage for finding semantically similar names but does not explicitly state when to use this tool versus alternatives like search_ens_names. It provides useful context about statuses and the GRACE_PERIOD restriction, but lacks explicit when-not or alternative recommendations.

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

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

No annotations provided, so description carries full burden. It discloses return payload contents ('tool call counts, success rates, and average latency'), which substitutes for the missing output schema. Safety profile implied by 'Get' but not explicitly stated.

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 efficient sentences with zero waste. First states the action, second clarifies return values. Appropriately front-loaded.

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

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

For a zero-parameter observability tool, the description is complete. It compensates for the missing output schema by detailing the returned statistics.

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?

Input schema has 0 parameters, which per instructions establishes a baseline of 4. Description correctly implies no filtering parameters are needed.

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

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

Description uses specific verb 'Get' with resource 'usage statistics' and scope 'for this MCP server session', clearly distinguishing it from the sibling ENS management tools (register, transfer, renew, etc.).

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 clear context ('for this MCP server session') indicating this is for monitoring/debugging the current interaction, though it lacks explicit exclusions or named alternatives.

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

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

With no annotations provided, the description carries full burden and successfully discloses data sources (Wikipedia/Wikidata, search interest, comparable sales), return structure (value range, context, narrative), and methodology. Could explicitly state read-only nature, though 'Get' implies this.

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 compact components: methodology explanation, return value specification, and usage context. No redundant words. Critical information (valuation basis) front-loaded in first sentence. No waste.

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

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

No output schema exists, so description must explain return values—it comprehensively lists estimated range, background context, comparable sales, and narrative. Methodology transparency is strong. Minor gap: no mention of rate limits or confidence level interpretation.

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

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

Schema has 100% description coverage ('ENS name or label to value'), establishing baseline 3. The description references 'ENS name' but does not add syntax details, format constraints, or examples beyond what the schema already provides.

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

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

The description clearly states the specific action ('Get a confidence-rated valuation'), resource ('ENS name'), and distinguishes from siblings by focusing on pricing analysis rather than registration, transfer, or management operations. The methodology details (comparable sales, entity recognition, etc.) further clarify scope.

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

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

Provides clear positive guidance ('Essential for pricing decisions') establishing when to use the tool. Lacks explicit negative guidance ('when not to use') or alternatives, but the tool's unique analytical function among operational siblings makes its purpose self-evident.

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

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

No annotations provided, so description carries full burden. Compensates well by detailing return structure (label, tags, expiry, prices) and authentication fallback logic. Missing explicit safety/read-only declaration or rate limit disclosure.

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

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

Four sentences across two paragraphs with zero waste. Front-loaded with core action, followed by return values, use case, and authentication behavior. Every sentence 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?

No output schema exists, but description partially compensates by listing return fields. Covers authentication complexity adequately. Minor gap: lacks explicit statement that this is a safe read operation, which would be helpful given the many mutation siblings.

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

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

Schema coverage is 100%, establishing baseline 3. Description adds critical semantic detail that wallet can be omitted under ERC-8128 authentication, overriding the schema's 'required' constraint. Does not add syntax details beyond schema for limit/offset.

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

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

States specific verb ('Get') + resource ('ENS names') + scope ('owned by a wallet address'), and distinguishes from siblings like get_name_details (single name) or search_ens_names (search) by emphasizing portfolio-level 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?

Provides clear context ('Useful for portfolio analysis and wallet profiling') and explains authentication-based parameter omission behavior. Lacks explicit when-not-to-use guidance or named sibling alternatives.

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

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

No annotations, so description bears full burden. Discloses return payload, signing requirement, subsequent POST step, fee structure (1%), and need for WETH approval. Covers key behavioral aspects but omits error handling and edge cases.

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?

Concise yet comprehensive. Front-loaded with clear purpose, then logical flow of steps. Every sentence adds value without redundancy. Tip included at end for practical guidance.

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

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

No output schema, but describes return and subsequent actions. Explains settlement in WETH, marketplace fee, and NW-native nature. Could mention error responses or prerequisites but adequate for the tool's complexity.

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

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

100% schema coverage, so baseline 3. Description adds context: amountEth used as WETH, currency default behavior, expiry default, and wallet as maker. Enhances understanding beyond schema definitions.

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

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

The description clearly states the tool's purpose: placing an offer on a registered ENS name via Seaport 1.6. It specifies the return type (unsigned Seaport OrderComponents) and distinguishes from sibling tools like accept_offer and cancel_offer.

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 advises using get_valuation first for fair market value. Implicitly differentiates from accept/cancel by focusing on making offers. Does not explicitly list exclusions but provides sufficient context for when to use.

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

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

No annotations provided, so the description carries full burden. It details the return fields (status, expiry, owner, pricing, ranked actions). While it doesn't mention side effects or auth requirements, the tool is clearly read-only and non-destructive, making the transparency sufficient.

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

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

The description is well-structured: starts with purpose, then lists return fields, then distinguishes from siblings. Every sentence is relevant and earns its place. No unnecessary words.

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

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

Given 2 parameters with full schema coverage and no output schema, the description adequately covers what the tool does and returns, enabling correct selection and invocation. No gaps.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds context about the overall purpose but does not add new parameter-specific meaning. 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 it provides a 'one-shot management report for an ENS name' and lists specific outputs (registration status, expiry, ownership, etc.). It also distinguishes itself from sibling tools like get_name_details and get_valuation by focusing on status/recommendation queries.

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 it is the ONLY tool for queries like 'management report', 'full overview', 'health check', etc., and recommends preferring this over calling get_name_details + get_valuation separately. It also clarifies when to use get_name_details instead (for marketplace data).

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

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

With no annotations provided, the description carries full disclosure burden and excels by revealing: (1) irreversibility of all fuse burning, (2) fuses expire when the name expires, (3) prerequisite dependencies (CANNOT_UNWRAP first), and (4) expiry constraints for child fuses (cannot exceed parent expiry). It accurately portrays the destructive, permanent nature of the operations.

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

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

The description is well-structured with clear visual hierarchy (bold headers, bullet lists) and front-loaded with the core concept. While lengthy, the complexity of ENS fuses and irreversible consequences justify the detail. Each section serves a distinct purpose: conceptual introduction, operational modes, valid fuse values, and critical warnings.

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 high complexity of irreversible blockchain permissions and lack of annotations, the description provides comprehensive coverage: it explains the domain concept (fuses as permission bits), enumerates all valid fuse values with semantics, specifies safety constraints, and includes prominent warnings about irreversibility. No output schema exists, but per guidelines, the description need not explain return values.

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?

While the schema has 100% coverage providing baseline documentation, the description adds crucial semantic context beyond the schema: detailed explanations of what each fuse constant does (e.g., 'prevents unwrapping', 'prevents transfers'), the hierarchical relationship between fuses (CANNOT_UNWRAP as prerequisite), and domain-specific constraints that help the agent understand valid parameter combinations.

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 defines the tool's purpose using specific verbs (manage/burn/read) and resources (fuses on wrapped ENS names). It effectively distinguishes this from sibling tools like manage_ens_name or wrap_name by focusing specifically on 'fuses' as permission bits, and details the three distinct operational modes (read, burn_owner_fuses, burn_child_fuses).

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

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

Provides explicit guidance on when to use each mode (read vs. burn operations) and critical prerequisites ('CANNOT_UNWRAP must be burned first before any other fuse'). It clearly differentiates between owner-controlled fuses (for names you own) and parent-controlled fuses (for subnames you parent), establishing clear contextual boundaries for invocation.

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

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

No annotations are provided, so the description carries the full burden. It discloses important behavioral details: transactions are bundled into multicalls (all-or-nothing), one-time wrap setup for unwrapped parents, and that only gas costs apply. However, it lacks error conditions (e.g., missing parent ownership) and prerequisites.

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

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

The description is efficiently structured with the main action front-loaded. It contains 6 sentences, each adding distinct information, though some redundancy exists (e.g., repeating 'bulk-create' concept). Overall, it is concise and well-organized.

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

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

Given no output schema, the description adequately explains the return value (steps array). It covers the workflow for wrapped/unwrapped parents and the batching mechanism. However, it omits the 50-subname batch limit mentioned in the schema and does not cross-reference sibling tools for related operations.

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

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

Schema coverage is 100%, so the description primarily reiterates schema content. It adds value for 'allowOverwrite' by noting it is 'destructive — replaces current owner,' which goes beyond the schema's description. This slight addition justifies a 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 clearly states 'Bulk-create subnames under a parent ENS name in a single transaction,' providing a specific verb and resource. It distinguishes from siblings like 'bulk_register' (top-level domains) and 'bulk_set_records' (setting records only) by focusing on subname creation under an existing parent.

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 it's 'designed for agent fleet deployment' and gives examples, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., creating a single subname via another tool).

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

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

With no annotations, the description bears full burden. It explains the multi-step process, required final set_ens_records step, and references to ENSIP standards. However, it does not mention auth requirements, rate limits, or potential failures.

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

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

The description is lengthy with detailed standards references (ENSIP-25, ENSIP-26, ERC-8004, ERC-8217). While front-loaded with the core purpose, it could be more concise by summarizing the technical details.

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

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

Given the tool's complexity (5 parameters, nested objects, no output schema), the description adequately explains the return of a recipe and transaction data, making the tool's usage complete enough for an agent.

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

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

Schema coverage is 100%, and the description adds significant value by explaining the purpose parameter's role, default budget, naming style options, and detailed context for agentRegistry linking to on-chain identity.

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 provisions a complete ENS identity for an AI agent, specifying the verb (provision), resource (ENS identity), and distinguished from siblings like register_agent and set_ens_records by describing the multi-step recipe it returns.

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

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

The description includes an important note that the AI must execute all steps in the recipe, implying that the tool is for complete setup, but lacks explicit when-not-to-use or alternative guidance beyond the 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?

No annotations provided, so description carries full burden. Discloses key behaviors like auto-detection, marketplace search, commit-wait flow, and CHOOSE_LISTING status. Does not mention auth or rate limits, but flows are well explained.

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

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

Well-structured with clear paragraphs for different flows. Front-loaded with purpose. Every sentence adds value, though could be slightly more concise.

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

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

No output schema, but description explains expected outputs for both cases (registration recipe, CHOOSE_LISTING, buy transaction). Covers both available and listed names adequately. Missing edge case of unavailable/unlisted name but 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 coverage is 100%, baseline 3. Description adds significant meaning beyond schema: explains workflow, auto-detection, orderHash usage, duration details, and deprecation of durationYears. Goes beyond baseline.

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

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

Description clearly states the tool purchases ENS names, distinguishes between available and listed names, and explains the auto-detection flow. It is specific and differentiates from sibling tools like bulk_register or create_listing.

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 extensive guidance on when to use auto vs explicit action, handling multiple listings, and the commit-wait-register process. Lacks explicit exclusions for alternatives, but context makes the usage clear.

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

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

With no annotations provided, the description carries the full burden of explaining behavioral traits. It successfully discloses the authentication requirement (ERC-721 token ownership), the mechanism (syncing registry to token owner), and side effects (potential resolver clearance). However, it omits standard blockchain operational details like gas costs or transaction irreversibility.

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 follows an effective inverted pyramid structure, opening with the core purpose, followed by mechanism explanation, a scannable bulleted list of specific use cases, and concluding with prerequisites. Every sentence contributes unique value, with zero redundancy or filler content.

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

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

Given the complexity of ENS's two-layer ownership model and the absence of annotations or output schema, the description adequately covers the business logic, edge cases, prerequisites, and post-operation considerations. It explains the relationship between the Registry and BaseRegistrar sufficiently for an agent to understand when reclamation is necessary.

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

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

The input schema has 100% description coverage, documenting both the name format and the owner address pattern with constraints. The description reinforces the ownership constraint mentioned in the schema but does not add additional semantic meaning, syntax examples, or format details beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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

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

The description opens with a precise action ('Reclaim ENS Registry ownership') targeting a specific resource ('.eth name'). It clearly distinguishes this tool from siblings like `transfer_ens_name` by explaining the specific mechanics of syncing the ENS Registry owner to the BaseRegistrar token owner, clarifying this is a recovery/sync operation rather than a standard transfer.

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 provides explicit usage scenarios under 'Used when:' listing three specific edge cases (direct safeTransferFrom bypass, out of sync ownership, contract migration). It also states the prerequisite that 'The caller must own the BaseRegistrar ERC-721 token' and notes the follow-up action of setting the resolver, providing clear boundaries for when the tool is appropriate.

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

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

With no annotations provided, the description fully discloses behavior: returns an unsigned transaction, default route binds agent to name (control follows name, OpenSea shows identity, transfers with name), alternative route mints NFT to wallet. It also warns about the necessary follow-up action to write the binding record, ensuring the agent is verifiable.

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

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

The description is well-structured, front-loaded with the core purpose, then explains routes, defaults, and an important note. Every sentence adds value without redundancy or extraneous information.

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

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

Given the tool's complexity (4 parameters, enum, no output schema), the description is complete: it explains the return value, net effect, implications of each route, and post-requisites. It even mentions how to extract the agentId from the receipt event, compensating for the lack of output schema.

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

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

Schema coverage is 100%, baseline 3, but the description adds substantial meaning: name must be owned, route explains implications (adapter vs direct), agentURI defaults to live-updating hosted file, walletAddress is auto-filled and has requirements. These details go well beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: register an ENS name as an ERC-8004 agent identity, returning a ready-to-sign transaction. It specifies the verb (register), resource (ENS name), and context (Ethereum mainnet). It also distinguishes between two routes (adapter and direct), making it unique among sibling tools like 'provision_agent_identity'.

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 when-to-use context: registering an ENS name as an agent identity. It states prerequisites (must own the name, wallet address requirements) and post-conditions (must call set_ens_records after confirmation). It does not explicitly exclude alternative tools, but the guidance is strong enough for correct selection.

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

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

Discloses key behaviors: single transaction, returns transaction data with 5% buffer, batch uses Multicall3, no minimum renewal. No annotations exist, so description carries full burden. Minor gap: does not mention any required token allowances.

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?

Well-structured: purpose, simplification over registration, duration details, use cases, batch behavior. Each sentence adds value without redundancy.

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

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

Covers all relevant aspects: return value (transaction data with pricing), batch behavior, deprecated parameter, duration bounds, use cases. No output schema, but description compensates.

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%, but description adds substantial value: explains years deprecated, duration examples (7 days=1 week), default 365, min 1, max 36500. Adds meaning beyond 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?

Clearly states the tool renews ENS names or batches, contrasting with registration. Sibling tools include purchase_name and bulk_register, so it distinguishes itself as a renewal action.

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

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

Provides explicit use cases (extend, gift, protect) and context (anyone can renew, no commit/reveal). Lacks explicit when-not-to-use or alternative tools, but context is clear.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the data source (ERC-8004 registry via 8004scan), scale (110,000+ agents), and detailed return values (identity, ENS, reputation scores, protocols) compensating for the missing output schema. Lacks rate limit or caching details.

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

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

Well-structured with purpose upfront, followed by data source context, return value disclosure, and actionable examples. No redundant sentences. The length is appropriate for a 5-parameter tool lacking an output schema, with high information density throughout.

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?

Thoroughly complete given constraints. Compensates for missing output schema by detailing return fields (identity, wallet/ENS, reputation, verification status). Compensates for missing annotations by describing the live registry data source and indexing scope. Schema coverage is full, so no parameter gaps exist.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds value through the examples section, which semantically maps natural language intent ('trading agents on Base') to specific parameter usage (chain filter), helping agents understand query construction beyond the raw schema definitions.

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

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

The description opens with a clear verb ('Search') and specific resource ('AI agent directory'), listing search dimensions (name, capability, protocol, reputation). It distinguishes itself from sibling management tools (approve_operator, provision_agent_identity) by emphasizing the read-only registry search function via ERC-8004/8004scan.

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 three concrete examples mapping natural language queries to specific parameter combinations (chain for Base, capabilities for MCP, minReputation for scores). However, it does not explicitly name sibling alternatives like get_agent_reputation for direct reputation lookups vs. directory searches.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully explains the return structure ('structured results with name, price, owner, tags, and availability info') since no output schema exists, and discloses key behavioral traits like 'semantic similarity across 3.6M names' and 'AI-generated suggestions.' It lacks explicit read-only or rate limit disclosure.

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 appropriately front-loaded with the core purpose, followed by well-organized bullet points that efficiently communicate distinct capabilities. Every sentence earns its place; the bulleted examples are information-dense and the final sentence clarifies return values. Slightly verbose but justified by the richness of examples.

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

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

Given the absence of an output schema, the description adequately compensates by detailing what the tool returns. For a single-parameter tool, the description provides sufficient complexity coverage by explaining both input patterns and output structure. No critical gaps remain for an agent to invoke 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?

The schema has 100% description coverage for the single 'query' parameter, establishing a baseline of 3. The description adds significant semantic value beyond the schema by categorizing the types of natural language queries supported (filtered, concept, creative, collection, activity, availability, bulk), helping the agent understand what kinds of inputs produce good results.

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 ('Search ENS names') and immediately distinguishes this tool from siblings by emphasizing the 'natural language' interface. The bullet points further differentiate it from structured alternatives like check_availability or get_similar_names by showing diverse query capabilities (concept search, creative search, etc.).

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 through seven specific query type examples with natural language patterns (e.g., '4-letter words under 0.1 ETH', 'is coffee.eth taken?'). While it doesn't explicitly name sibling alternatives or state 'when not to use,' the comprehensive examples effectively guide the agent on when to select this tool for natural language queries.

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

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

With no annotations provided, the description carries the full burden. It discloses 'Powered by semantic search' (revealing the matching algorithm) and 'curated ENS sources' (indicating scope limitations). It could improve by mentioning result format or pagination behavior, but the core behavioral traits are 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?

Two dense sentences followed by a clear negative constraint. Every clause adds value—either expanding scope (governance, protocol details) or constraining usage. No filler words or redundant restatements of the tool name.

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 3-parameter search tool with 100% schema coverage but no output schema, the description adequately covers the knowledge domain and search methodology. It implies return values through the 'limit' parameter reference to 'results', though explicitly stating the return structure (documents/snippets) would make it a 5.

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?

While the schema has 100% description coverage (baseline 3), the description adds significant semantic context by listing concrete query examples like 'Vitalik', 'Nick Johnson', 'ENSv2', 'resolvers', and 'subnames'. This helps the agent formulate valid queries beyond the generic schema 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 opens with a specific verb ('Search') and clearly defines the resource ('ENS knowledge base'), then enumerates specific content types (governance proposals, Farcaster casts, etc.). It effectively distinguishes from siblings by explicitly contrasting with 'name valuations, market data, or availability checks' which other tools handle.

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

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

Provides explicit negative constraints: 'Do NOT use this for name valuations, market data, or availability checks — use the other tools for those.' This directly guides the agent toward alternatives (get_valuation, check_availability, get_market_activity) for those specific use cases.

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

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

With no annotations provided, the description carries full behavioral disclosure burden and excels. It explicitly states the tool returns 'encoded transaction calldata ready to sign and broadcast' rather than executing on-chain, discloses the multicall batching for gas optimization, and notes compatibility with specific wallet frameworks (Coinbase AgentKit, ethers.js).

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 lengthy but appropriately structured for the complexity: core purpose first, followed by supported record types, common keys, ENSIP standard details, and finally transaction handling. Every paragraph serves a distinct purpose, though the ENSIP sections could be slightly more compact.

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 high complexity (nested objects, blockchain context), zero annotations, and no output schema, the description comprehensively covers all gaps. It explains the return value format (calldata), prerequisites (ownership), gas optimization strategy (multicall), and integration patterns (wallet frameworks), leaving no critical behavioral ambiguity.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds significant value by enumerating common text record keys (avatar, com.twitter, ai.agent), explaining ENSIP-25/26 conceptual mappings ('creates a verifiable on-chain binding'), and providing concrete examples of address formats (ETH, BTC) and content hash types (IPFS/IPNS).

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 and resource ('Set ENS resolver records for a name you own'), clearly distinguishing this from siblings like bulk_set_records (implied by singular 'name'), set_resolver (changes resolver vs records), and set_primary_name (reverse record). It explicitly scopes the operation to owned names only.

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 establishes clear prerequisites (must own the name) and scope (single name, multiple records batched via multicall). While it doesn't explicitly name siblings as alternatives, the singular 'name' parameter and multicall explanation implicitly guide users toward bulk_set_records for multiple names. It clearly states this returns calldata for signing rather than executing.

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?

Given no annotations, the description carries the burden well by disclosing the replacement behavior ('setting a new one replaces the previous'), authorization requirements, and the concept of reverse resolution. Could explicitly mention transaction/gas implications, but the signing requirement in schema context helps.

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?

Well-structured with purpose front-loaded, followed by helpful example, bulleted requirements, conditional guidance, and behavioral note. Every sentence provides necessary information without redundancy.

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

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

Comprehensive for a mutation tool with no output schema or annotations. Covers prerequisites, side effects, sibling differentiation, and operational constraints. Slightly short of perfect only because return values (transaction hash, etc.) aren't described, though not strictly 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 coverage is 100%, with both parameters fully documented in the schema (including examples and signing context). The description provides conceptual context for the parameters but doesn't need to add semantic details beyond the baseline.

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

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

The description clearly states the specific action ('Set the primary ENS name'), the resource type (reverse resolution), and distinguishes from sibling tools by explicitly mentioning when to use 'set_ens_records' instead.

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

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

Excellent guidance with explicit prerequisites (ownership, address record matching, wallet ownership) and clear alternative tool reference ('use set_ens_records first') when preconditions aren't met.

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

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

No annotations provided, so description carries full burden. It warns about records becoming invisible after switching, discloses the 'public' shortcut address, and implies this is a mutation operation. This provides sufficient 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?

Well-structured with paragraphs, bullet points for common use cases and a warning. Every sentence adds value, no redundancy. Front-loaded with purpose, then details.

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 purpose, parameters, and behavioral implications (records invisible). It does not describe return values, but no output schema exists for this tool, so it is acceptable. Completeness is adequate for a simple mutation tool.

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

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

Schema coverage is 100%, but description adds value beyond schema: explains 'name' is an ENS name with example, clarifies 'resolver' can be 'public' as a shortcut to a specific address, and explains the role of a resolver. This enhances understanding of 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 changes the resolver contract for an ENS name, using specific verbs ('Change', 'points'). It distinguishes from siblings by listing common use cases (migrating, custom resolver, fixing missing resolver) and provides context about what a resolver 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 gives explicit use cases (migrating, custom resolver, fixing missing resolver) and a warning about records not being visible after switching. It does not explicitly say when not to use this tool versus alternatives, but the guidance is clear enough for most scenarios.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals that the tool executes a single Seaport transaction, caps at 20 names (requiring repeated calls for more), selects cheapest-first across multiple marketplaces, skips orders that sold since discovery with refunds, and delivers directly to the buyer. However, it does not explicitly mention any authentication or authorization requirements beyond providing a wallet address, nor does it state potential fees or edge cases like no matching names. Still, it is fairly comprehensive for a tool with no annotations.

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

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

The description is well-structured and front-loaded: it starts with the core purpose, then usage guidance, then parameter details, execution details, and response. At about 170 words, it is reasonably concise with no unnecessary fluff. Every sentence adds value, though some minor redundancy could be trimmed. Overall, it is clear 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?

Given the tool's complexity (9 parameters, no output schema), the description covers most essential aspects: what it does, when to use it, how to configure the cohort and bounds, execution details, and response contents (what was swept, total, and count of matches outside bounds). It does not explicitly cover error handling or edge cases (e.g., if no names match), but the mention of skipping sold orders and refunding excess provides some resilience context. For a tool of this complexity, the description is substantially 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 100% description coverage, so the baseline is 3. The description adds value by explaining how parameters interact: 'Bound the sweep with 'count' and/or 'maxBudgetEth', plus an optional 'maxPriceEth' per-name cap.' It also elaborates on the selection algorithm and how constraints work together, which goes beyond individual parameter descriptions. This additional context justifies a score above baseline.

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

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

The description explicitly states the tool's purpose: 'buy the CHEAPEST N listed ENS names... in ONE Seaport transaction.' It clearly identifies the verb (buy/sweep) and resource (ENS names), and distinguishes it from the sibling tool 'batch_purchase' by noting that this tool is for unspecific cheapest names rather than specific names.

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

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

The description provides explicit guidance on when to use this tool: 'Use this when the user wants "the cheapest N", "sweep the floor", or "buy up to X ETH of" a cohort — rather than naming specific names (that's batch_purchase).' This clearly states the usage scenario and names the alternative tool (batch_purchase) for different needs.

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

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

With no annotations, the description fully discloses behavioral traits: automatic wrapped/unwrapped detection, full ownership transfer, and that resolver records are unaffected. Includes a warning about recipient gaining complete control, ensuring the agent understands consequences.

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?

Description is concise and well-structured: starts with action, then automatic detection, requirements, warnings, and note on resolver records. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description covers input semantics, behavior, and side effects (resolver records unchanged). It does not specify the return format (likely transaction hash), but this is common knowledge for transfers. Overall, adequately complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaning beyond schema: explains that toAddress can be an ENS name (automatically resolved), fromAddress must sign, and name must be registered. This enriches parameter understanding.

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

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

Description clearly states 'Transfer ownership of an ENS name to another wallet address.' It specifies the verb 'transfer' and the resource 'ENS name'. This distinguishes it from siblings like bulk_transfer_ens_names (multiple names) and set_ens_records (records management).

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

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

Provides explicit requirements: fromAddress must own, name must be registered, toAddress can be address or ENS name. Also explains automatic detection of wrapped/unwrapped. Does not explicitly contrast with alternatives like using bulk_transfer_ens_names for batch transfers, but the guidance is clear and sufficient for correct usage.

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

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

With no annotations provided, the description carries full burden and excels: it discloses the token standard conversion (ERC-1155 to ERC-721), the destructive side effect (all fuses cleared), and the irreversible blocking condition (CANNOT_UNWRAP fuse). This gives the agent complete context on state changes and risks.

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

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

Front-loaded with the core action, followed by technical details, side effects, failure modes, and use cases. Every sentence serves a distinct purpose; no redundancy. The bulleted use cases provide scannable context without verbose prose.

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?

Comprehensive for a mutation tool with no output schema. Covers the transformation mechanics, fuse behavior, prerequisites for failure, and practical use cases. Minor gap: does not mention return value structure, though this is acceptable given no output schema exists to document.

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 ('ENS name to unwrap', 'Address of the current wrapped name owner'), establishing baseline 3. The description mentions 'owner' in the failure context but does not add syntax details, format constraints, or semantic clarifications beyond what the schema already provides.

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

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

The description opens with a specific verb ('Unwrap') and identifies the exact resource transformation (from ENS NameWrapper to BaseRegistrar). It clearly distinguishes this from the sibling tool 'wrap_name' by specifying the direction (back to BaseRegistrar) and token standard conversion (ERC-1155 to ERC-721).

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

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

Provides explicit failure conditions ('Will fail if the CANNOT_UNWRAP fuse has been burned — that restriction is permanent') and three specific use cases that clarify when to use this versus alternatives. The use cases implicitly contrast with 'wrap_name' by emphasizing 'reverting' and 'regaining full control'.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return values (confidence score, label, signals, summary) and implies read-only analysis. It could add details about side effects or dependencies, but the provided info 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 waste: front-loaded purpose, then mode explanation, then output summary. Every sentence is informative.

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

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

No output schema exists, but the description lists all return fields. Parameter descriptions are complete. The tool's functionality is fully covered for the complexity level.

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

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

Schema coverage is 100% with each parameter described; the description adds the mode-switching logic (either tx_hash or all live parameters). This adds value beyond the individual schema descriptions.

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

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

The description clearly states the tool checks for wash trades in ENS sales and distinguishes two modes of operation (tx_hash lookup vs live analysis). No sibling tool handles wash trade detection, so it is well-differentiated.

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

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

Provides clear context on when to use each mode (tx_hash for pre-computed scores, live parameters for on-demand analysis). Does not explicitly state when not to use the tool or mention alternatives, but the usage guidance is sufficient for a specialized tool.

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

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

No annotations provided, so description carries full burden. Discloses critical behavioral traits: returns a 'two-step transaction recipe' (approve + wrap), emphasizes IRREVERSIBLE nature of fuses, and explains the dependency constraint (CANNOT_UNWRAP must be burned first). Lacks explicit error conditions (e.g., what happens if name already wrapped).

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?

Well-structured with front-loaded purpose, followed by technical context, benefits, return format, and exhaustive fuse reference. The fuse list is lengthy but justified by the irreversible nature of the operation. No wasted sentences, though density is high.

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?

Comprehensive for a complex blockchain operation with no output schema. Compensates by describing the return structure (two-step recipe), explains domain-specific concepts (fuses, token standards), and provides safety-critical warnings about irreversibility necessary for agent decision-making.

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

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

Despite 100% schema coverage (baseline 3), description adds substantial value by enumerating all 7 valid fuse values with detailed behavioral explanations (e.g., 'prevents resolver changes'), which is critical for an irreversible operation. Also adds domain context about BaseRegistrar ownership.

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?

Opens with specific verb+resource ('Wrap an unwrapped .eth name into the ENS NameWrapper contract'), clearly distinguishing from siblings like unwrap_name and manage_fuses by specifying the exact contract and token standards involved (ERC-721 to ERC-1155 conversion).

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?

Implicitly defines when to use by specifying 'unwrapped .eth name' as input and explaining the transformation benefits. Warns about irreversible consequences of fuse burning. Could be improved by explicitly naming unwrap_name as the inverse operation or stating 'do not use if already wrapped'.

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