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?

Discloses full behavioral traits: groups into single transaction, auto-detects wrapper type, max 20 names, supports different recipients, resolves ENS name recipient, irreversibility, and that resolver records remain unaffected. No annotations provided, so description carries full burden and excels.

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 well-structured and informative, but slightly long with multiple paragraphs. Every sentence adds value, so it earns a high score despite length.

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 essential aspects: core action, benefits, prerequisites, limitations, error conditions, side effects, and post-transfer suggestions. No output schema, but description compensates with thorough behavioral and usage details for a 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?

Adds significant meaning beyond schema: explains toAddress can be 0x or ENS name with auto-resolution, warns against using get_name_details, emphasizes fromAddress must own all names. Schema coverage is 100%, but description enriches both parameters with practical usage 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 clearly states the tool transfers multiple ENS names in a single transaction via Multicall3, distinguishes itself from sibling 'transfer_ens_name' by being bulk and cheaper/faster, and specifies auto-detection of wrapped vs unwrapped 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?

Provides explicit when-to-use context (cheaper/faster than single transfers), a conversational workflow (get_wallet_portfolio, confirm, then use), conditions (must own names, valid addresses, not expired), and alternatives (bulk_set_records after transfer).

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?

Discloses statuses, registerability, premium handling, validation of ENS character rules, and .eth suffix flexibility. No annotations provided, so description carries burden; covers key behavioral traits but misses cost/auth/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?

Front-loaded with purpose, then critical warnings, then details. Moderately long but each sentence adds value. Could be slightly tighter but 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?

Covers input format, constraints, output fields, status explanations, registerability, premium, and validation. Missing error handling details but sufficient for a simple lookup tool with no 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%, description adds examples, max items, and format rules beyond the schema's brief description. Provides concrete examples and ties to workflow (enumerate_entities), adding meaningful 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?

Clearly states it checks availability of ENS names and returns status, owner, and expiry. Distinct from enumerate_entities but doesn't explicitly differentiate from all siblings like get_name_details.

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 warns against using invented names, instructs to use enumerate_entities first, and explains when to use this tool (for verified labels). Also clarifies nuances like GRACE_PERIOD not registerable and PREMIUM_AUCTION registerable with premium.

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?

With no annotations, the description fully bears the burden. It discloses that the tool returns verified, correctly-spelled labels, grouped by status, with proper name and ENS label. It explains why this tool exists (avoid misspelling) and what not to do.

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 long but well-structured, front-loading the core purpose. Every sentence adds value, though some redundancy in examples could be trimmed. Still, it remains clear and instructive without being bloated.

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 is provided, but the description explains the return format (list grouped by status, each entry with proper name and ENS label). Together with detailed parameter info and usage guidance, it is fully complete for a two-parameter 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% and description adds significant extra context: for 'category', it specifies to strip qualifiers and be specific; for 'filter', it explains each enum value in plain terms. Adds meaning 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 enumerates ENS-friendly labels for finite real-world entity categories and reports availability. Specific examples and explicit differentiation from sibling tools like search_ens_names and check_availability solidify its purpose.

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

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

Extremely detailed when/not-to-use guidance. Explicitly states 'USE THIS for ANY finite set' and lists exclusions (vibes, ENS-native, single names). Even warns against using model's own context for enumeration, with examples of misspellings.

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?

No annotations provided, so the description carries full burden. It explains caching behavior, conservative computation (seller-wallet boost off), that results are from the same engine as get_valuation, and only genuine discounts are surfaced (20%+, MEDIUM+ confidence, real comps). It also warns against inflating fair values or padding results.

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?

Although long, the description is well-structured and front-loaded. It starts with the core purpose, then details the engine, usage, and exclusions. Every sentence adds necessary information; 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?

Given no output schema, the description explains the output fields (estimatedValueEth.mid as anchor, discountPct, confidence, comps) and handles edge cases (fewer results means not genuine discounts). It covers all aspects an agent needs 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?

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining defaults (minConfidence floored at MEDIUM, never returns LOW), range constraints (minDiscountPct default 20%), and caveats (avoid huge sentinels for maxLength/maxPriceEth). This goes 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 it scans the ENS marketplace for undervalued names, returning ranked opportunities with discount, fair-value range, confidence, and comparable data. It distinguishes itself from sibling tools like search_ens_names and get_valuation by specifying its unique value proposition.

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 when-to-use scenarios (e.g., 'best value', 'bargains') and when-not-to-use (e.g., named collection floor queries), with specific alternative tools like search_ens_names or sweep. This makes the decision boundary 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, 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, the description fully discloses that the tool returns raw activity, lists return fields (name, price in ETH, buyer/seller, timestamp), and states sorting order (most recent first). It also clarifies it does not make authenticity judgments.

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 4 sentences, front-loaded with purpose, and every sentence adds value. No filler or redundancy.

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

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

For a tool with no output schema and 3 parameters, the description covers what the tool does, what it returns, ordering, and even provides a sibling alternative. It is fully adequate for agent 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 coverage is 100%, so the description doesn't need to add much. It mentions filtering by event type and limit/offset, but the schema already fully describes parameters. No additional semantic value 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 starts with a clear verb 'Get' and resource 'ENS marketplace activity', listing specific event types (sales, listings, etc.). It explicitly distinguishes itself from the sibling tool 'wash_check' by stating this is raw activity 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?

The description provides explicit when-not-to-use guidance by clarifying it makes no wash-trading judgment and directs the user to 'wash_check' for that purpose. It also describes filtering by event type and default sorting.

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 bears full responsibility for behavioral transparency. It discloses that the tool makes no wash-trading/authenticity judgment (a behavioral limitation), explains special cases for creationDate (Vickrey-era vs. other names), and instructs the agent to use specific fields for certain questions. It does not disclose auth needs or rate limits, but it is sufficiently transparent for a read-only lookup tool.

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

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

The description is verbose but packed with necessary detail. It is front-loaded with the main purpose and enumerates fields, but includes long explanatory sentences that could be streamlined. Every sentence serves a purpose, but a more concise structure would improve readability.

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

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

Given the tool's complexity (many return fields) and lack of output schema, the description is remarkably complete. It explains key fields (creationDate, resolver, isPublicResolver, wrapped status, fuses) and provides usage instructions (e.g., 'always mention creationDate', 'use these to answer resolver questions'). It also cross-references the sibling tool wash_check for 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?

Schema coverage is 100% with one parameter ('name'). The description adds value beyond the schema by clarifying that 'name' can be an ENS name or label (e.g., 'vitalik' or 'vitalik.eth'), and provides implicit context that the tool works with both forms. This extra detail is useful for agents invoking the tool 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 specifies the tool's purpose: 'Get full details for a specific ENS name' and enumerates the specific data fields returned (owner, expiry, creation date, tags, listings, etc.). It distinguishes the tool from siblings by providing context on when to use it for creation date, resolver, wrapped status, and wash trading questions.

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: for answering creation date questions, resolver questions, and wrap/unwrap/fuse questions. It also explicitly mentions an alternative tool (wash_check) for wash trading judgments, helping the agent decide when not to use this tool. However, it does not provide comprehensive when-not-to-use guidance for all sibling tools.

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

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

With no annotations provided, the description carries full burden and 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?

With no annotations, the description fully discloses that the tool never spends money (builds unsigned transaction), explains return value, pricing with buffer, and that anyone can renew any name.

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 sections and bullet points, but lengthy. Agent instructions (conversational flow) could be external. Still clear and 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?

Covers all aspects: single/batch, duration semantics, safety (no spend until sign), pricing, and edge cases (expired names). No output schema, but explains return value.

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 context: explains duration flexibility, deprecation of years, default, and batch behavior. Enhances understanding 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?

The description clearly states 'Renew an ENS name or batch of names' and specifies the verb (renew) and resource (ENS name). It distinguishes from siblings like purchase_name and manage_ens_name by focusing on renewal.

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 when-to-use (renewing names) and when-not-to (expired/premium names in batch renewals). Includes conversational flow and alternatives like get_wallet_portfolio for finding 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 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, the description fully discloses behavior: it performs semantic similarity across 3.6M names, AI-generated suggestions, returns structured results (name, price, owner, tags, availability). It states what it does not know (real-world entities). It does not explicitly mark as read-only but implies it's a search tool without 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 moderately long but well-organized with bullet points and clear sections. It is front-loaded with the core purpose and then details query types. Some redundancy exists (e.g., examples could be condensed), but overall it is efficient and readable.

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 single parameter and no output schema, the description provides comprehensive coverage: query types, return fields, limitations, and usage boundaries. It is fully self-contained and enables correct agent invocation without additional context.

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

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

Schema coverage is 100% for the single 'query' parameter, so baseline is 3. The description adds value with concrete examples ('cheap 3-letter words', 'is coffee.eth taken?') that are more informative than the schema description alone. However, it does not explain formatting rules beyond examples.

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 searches ENS names using natural language and lists specific query types (filtered, concept, creative, etc.). It distinguishes from sibling tools like enumerate_entities (real-world entities) and find_alpha (no collection param), making the purpose explicit.

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 says when to use this tool (for ENS name searches, floor/collection queries) and when not to (for real-world entities, use enumerate_entities; for alpha, find_alpha cannot handle collections). It provides clear alternatives and exclusion conditions.

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

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

No annotations provided, but the description fully discloses the search behavior: semantic search over curated sources, returns results with citations. It does not mention rate limits or auth needs, but for a read-only search tool this is adequate.

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

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

The description is front-loaded with the main purpose and then provides detailed usage guidelines. While it is somewhat long, every sentence earns its place by adding clarifying context or examples. Minor redundancy could be trimmed, 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?

The tool has no output schema, but the description explains it returns results with citations. It covers the search scope, usage hints, and exclusions. It could mention result format more explicitly, but for an agent the information is sufficient 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 is 3. The description adds value by explaining the purpose of each parameter beyond the schema, e.g., the query should be about ENS topics, source filter options, and the default limit of 6. This goes 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 searches the ENS knowledge base for governance, protocol, developer insights, etc. It explicitly distinguishes itself from sibling tools by specifying what NOT to use it for (name valuations, market data) and directs to other tools for those tasks.

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

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

Extensive guidance on when to use (e.g., 'how does X work', protocol mechanics) and when not to use (name valuations). Provides rationale for using the tool over general knowledge ('sourced, citable answer is the bar'), making it clear for the agent.

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

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

No annotations provided, but the description discloses key behaviors: returns calldata, batches in multicall, auto-encodes ENSIP-9 and contenthash, and supports ENSIP-25/26. However, it does not mention error conditions or prerequisites like resolver being set.

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 headers and bullet-point style sections. It front-loads the core purpose and gradually adds detail. Slightly verbose but still efficient for the complexity.

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

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

Given the tool's complexity (nested objects, multiple record types, no output schema), the description covers invocation, supported records, encoding, and return value usage adequately for an AI agent to invoke 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%, and the description adds significant extra context for each record type, including examples of common text keys, address encoding rules, and detailed explanations for agent registration and endpoint fields.

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 sets ENS resolver records for an owned name and returns calldata. It specifies supported record types and batching. However, it does not explicitly differentiate from the sibling 'bulk_set_records' 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 implies usage for owned names and explains how to use the returned calldata, but does not provide explicit guidance on when to use this tool versus alternatives like 'bulk_set_records' or when not to use it.

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 discloses that the tool bundles two transactions into a single sign-card and that setting a new primary replaces the previous. It could mention failure modes but overall 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 front-loaded with the purpose, uses short paragraphs, and every sentence adds necessary information. No fluff.

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

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

Despite no output schema, the description covers prerequisites, usage instructions, and post-call verification. For a simple tool with 2 params, this is complete.

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

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

Schema coverage is 100% with good descriptions; the description adds context like 'must sign the transaction' for walletAddress and explains the name format. Adds value 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?

The description clearly states the tool's function: 'Set the primary ENS name (reverse resolution) for a wallet address.' It explains the effect with an example and explicitly distinguishes it from sibling tools like 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 explicit requirements (ownership, ETH record match, wallet owner), instructs when to call ('when user says set my primary name'), and warns not to call set_ens_records separately. It also suggests verification with get_primary_name.

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?

Without annotations, the description carries full burden. It discloses that the tool auto-detects wrapper status, that resolver records are unaffected, and that full ownership is transferred. It also mentions the fromAddress must sign. However, it does not explicitly state that this is a write operation requiring a transaction, though that is implicit.

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

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

The description is well-structured with sections: purpose, automatic handling, requirements, warning. Every sentence adds value. It is slightly longer than necessary but remains focused and 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?

Given no output schema, the description covers key aspects: auto-detection, resolver records not affected, and error handling for recipient name resolution. It is complete for a single-transfer tool, though it could mention the response format or that it's a one-step call.

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 good descriptions. The description adds extra context: for 'toAddress', it explains ENS name resolution and warns against incorrect lookups; for 'fromAddress', it clarifies signing requirement. This adds value 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 'Transfer ownership of an ENS name to another wallet address.' It distinguishes the tool from siblings like 'bulk_transfer_ens_names' and 'manage_ens_name' by specifying automatic detection of wrapped/unwrapped names and direct handling of ENS name recipients without needing separate 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?

The description provides explicit requirements (fromAddress must own the name, name must be registered) and clear guidance on what NOT to do: never refuse a recipient that is an ENS name, never look up the recipient's owner via get_name_details. It does not list alternatives but the context of sibling tools implies this is for single transfers only.

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 provided, so description fully carries the burden. Lists return fields (confidence score, label, signals, seller profile, summary) and explains behavior (pulls recent sale and analyzes on demand). 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?

Single dense paragraph, front-loaded with purpose and usage, followed by parameter and output details. No redundancy, every sentence contributes.

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, description fully details return structure. Covers invocation, parameter roles, and behavioral context. Sufficient for an agent to select and 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%, baseline 3. Description adds value by clarifying 'label' is sufficient, optional fields are for enrichment, and instructing not to block on them. This goes 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?

Explicitly states verb 'assess', resource 'ENS name's sale(s)', and purpose 'wash trading detection'. Clearly distinguishes from siblings get_name_details and get_market_activity, which do not perform wash-trading judgments.

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?

Directs agents to route wash-trading questions here and avoid siblings. Provides explicit parameter guidance: pass only 'label' as required, never block on optional fields, and explains enrichment purpose.

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.