Name Whisper — ENS Intelligence Layer

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

Annotations declare destructiveHint=true, and the description adds atomic operation details (Seaport pulls WETH, transfers ENS name, pays fee), the 1% fee, and revert conditions. No contradiction with annotations.

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

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

The description is well-structured with a clear first sentence stating purpose, then atomic steps, then prerequisites. While dense, each sentence adds value; however, slight condensation 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?

Given the financial and atomic nature of the tool and lack of output schema, the description covers prerequisites, chain behavior, revert conditions, and references sibling tools for approval and verification. It 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 clear descriptions for both parameters. The description adds context: orderHash is the buyer's offer hash and walletAddress must own the ENS name. It also references get_name_details for confirmation.

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 action ('Accept a standing offer on an ENS name you own') and the output ('Returns unsigned Seaport fulfillOrder() calldata'). It distinguishes from sibling tools like 'create_listing' and 'make_offer' by focusing on acceptance.

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 ('Before accepting: you must have approved Seaport...'), provides a prerequisite ('Use approve_operator if needed'), and suggests verifying the offer ('Use get_name_details to see the offer hash'). It also explains when the transaction will revert.

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?

Beyond annotations (destructiveHint=true), description warns that an approved operator can transfer ANY token owned by approver on the contract, calls out 'approval drain' attack. Adds critical behavioral context not available from annotations 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?

Well-structured with clear sections: purpose, contracts, use cases, addresses, warning. Every sentence earns its place; no 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?

Lacks description of return values or transaction outcomes (e.g., transaction hash). For a mutation tool with no output schema, this is a notable gap. Otherwise covers operation details thoroughly.

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. Description adds value by specifying that 'base_registrar' is ERC-721 and 'name_wrapper' is ERC-1155, and provides contract addresses. However, no additional detail on 'owner' or 'operator' 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?

Clearly states it approves/revokes an operator for ENS contracts, identifies three specific contracts, and explains it's setApprovalForAll (all tokens). Distinguishes from sibling tools by emphasizing broad scope of permission.

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?

Lists common use cases: wrapping names, marketplace approvals, batch operations, and revocations. Provides explicit security warning about approving untrusted addresses, guiding when to use cautiously.

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 provides extensive behavioral context beyond the annotations (which only indicate non-read-only, non-idempotent, non-destructive). It explains the return type (unsigned Seaport OrderComponents payloads), the required subsequent step (EIP-712 bulk signature and POST to submit-bulk), error handling (per-name errors collected in 'errors' field, partial success), and prerequisites (operator approval on ENS token contract). No contradictions with annotations.

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

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

The description is well-structured and front-loaded with the main purpose. Each subsequent sentence adds value (return type, signing process, UX comparison, error handling, prerequisites). It is not overly verbose for the complexity of the tool, though it could be slightly more condensed 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?

Despite lacking an output schema, the description fully compensates by detailing the return format (unsigned Seaport OrderComponents payloads), the complete flow (signing + submission), error handling, and prerequisites. It covers all relevant aspects for correct tool usage, making it self-contained and 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%, so the baseline is 3. The description adds meaningful extra context: it clarifies that per-item validation errors go into the 'errors' array (reinforcing the schema description), specifies that walletAddress must own all names, and explains the default duration of 30 days. This goes beyond what the schema alone provides, warranting 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 begins with a clear verb-resource pair: 'Bulk-list up to 500 ENS names for sale on NameWhisper in one signing flow.' It specifies the exact action (bulk-list), resource (ENS names), platform (NameWhisper), and limits (up to 500). It also distinguishes itself from the sibling tool 'create_listing' by noting the UX advantage (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 explicitly states when to use this tool: for bulk listing up to 500 names with a single signing flow. It contrasts with 'create_listing' (cheaper UX) and notes that it is 'NW-native only' with listings staying on NameWhisper. It also mentions a prerequisite (operator approval) but does not explicitly list when not to use it, though that is implied.

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

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

Annotations indicate destructive hint (true). Description adds significant context: picks cheapest listing, uses Seaport partial fills for safety, skips canceled/sold orders, and details response format. No contradiction with annotations.

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

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

Description is comprehensive and well-structured, front-loading purpose and usage. Slightly verbose but all information is valuable.

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 tool purpose, usage context, safety (partial fills), failure handling, and provides enough detail about return format despite 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%, so baseline is 3. Description reinforces parameter purpose but adds no new semantic details 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 buys up to 20 specific ENS names in a single Seaport transaction across multiple marketplaces. It distinguishes from sibling tools like 'sweep' (floor sweep) and 'purchase_name' (single name).

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

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

Explicitly says to use when the user names exact names, and provides alternatives: use 'sweep' for floor sweeps and 'purchase_name' for single names or failed items.

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

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

Annotations indicate destructiveHint=true, which aligns with registration. Description adds context: 2-step process, 60-second wait, shared secret, reliance on name availability, and excess ETH refund. No contradictions with annotations and adds significant behavioral detail beyond structured metadata.

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

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

Extremely concise yet comprehensive. First sentence defines purpose, followed by benefit, detailed flow, constraints, and next steps. Every sentence earns its place; 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 lacking an output schema, the description covers the registration process, prerequisites (names must be available), and post-registration action. Minor omission: does not specify what the tool returns (e.g., transaction hashes), but for a mutation tool this is acceptable. Overall well-rounded.

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 parameter descriptions. The tool description reiterates some (e.g., duration applied to all names, walletAddress as owner) but does not add new meaning beyond the schema. The deprecated 'durationYears' parameter is clarified, but otherwise baseline score of 3 is appropriate.

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

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

Clearly states the tool registers multiple ENS names in bulk, distinguishing it from single-registration tools like purchase_name and post-registration tools like bulk_set_records. The two-transaction flow is explained.

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's cheaper/faster than one-at-a-time, supports up to 20 names, and recommends bulk_set_records afterward. Could improve by mentioning when not to use (e.g., if per-name secrets needed) but still provides clear guidance.

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

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

Annotations provide idempotentHint=true and destructiveHint=true. The description adds value by explaining the batching mechanism (multicall), cost efficiency, and supported record types. No contradiction with annotations.

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

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

The description is concise and well-structured, with no extraneous sentences. Every sentence adds value: purpose, batching benefit, supported records, flexibility of different/same records, limits, and ownership requirement.

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

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

Given the absence of an output schema, the description adequately covers the input parameters and behavioral constraints. It does not explain return values or error handling, but for a mutation tool this is acceptable as the agent can infer success from transaction completion.

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 baseline is 3. The description adds meaning by explaining the structure of nameRecords, the max 50 limit, the wallet ownership requirement, and enumerating supported record types (addresses, texts, content hash, agent registration).

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 multiple names in a single transaction, using a specific verb ('set') and resource ('ENS resolver records'). It distinguishes itself from the sibling tool set_ens_records by explicitly mentioning batch editing and cost efficiency.

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 (batch editing, cheaper than one-at-a-time) and provides constraints (max 50 names, owner/manager requirement). It does not explicitly state when not to use, but the contrast with set_ens_records is clear.

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

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

Discloses that transfer is irreversible, recipients gain complete control, and resolver records are unaffected. Also mentions automatic detection of wrapped/unwrapped names. These details go beyond the destructiveHint annotation.

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

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

The description is well-structured with clear sections: purpose, benefits, mechanics, usage guidelines, requirements, and warning. While fairly long, every sentence adds value, maintaining conciseness given 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?

Covers all necessary aspects: functionality, workflow with prerequisites, side effects, and behavior. No output schema exists, so return value description is not required. Adequately complete for a complex batch transfer 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%, so baseline is 3. Description adds value by explaining that toAddress can be an ENS name (resolved automatically) and advises against using get_name_details for resolution, providing extra context for correct parameter usage.

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 action ('transfer multiple ENS names in a single transaction via Multicall3 — bulk send') and distinguishes it from the sibling tool 'transfer_ens_name' by highlighting cost and speed benefits.

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 on when to use (batch transfers) vs alternatives, prerequisites (fromAddress must own all names), and a conversational flow including prior call to get_wallet_portfolio and explicit confirmation. States NEVER auto-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?

Annotations indicate destructiveHint=true and idempotentHint=true. The description adds significant context: it explains that the tool returns unsigned calldata, requires user signing and submission, and that after mining Seaport marks the order invalid. It also details atomic cancellation behavior with alsoCancel. No contradictions with annotations.

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

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

The description is concise and well-structured, with a clear opening sentence and practical details in subsequent sentences. While it uses multiple paragraphs, it is front-loaded with the core purpose and avoids unnecessary fluff. Could be slightly more terse but remains effective.

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 fully explains the return value (unsigned Seaport cancel() transaction calldata) and covers operational context: prerequisites, on-chain behavior, atomic cancellation, and cross-posting considerations. It is complete for a mutation tool with destructive and idempotent hints.

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

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

Schema description coverage is 100%, providing a baseline of 3. The description adds meaningful context for parameters: orderHash source ('from get_name_details or the orderbook'), alsoCancel purpose ('sibling order hashes to cancel atomically'), and walletAddress constraint ('must match the original offerer'). This elevates it above the baseline.

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

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

The description clearly states it cancels an active ENS name listing via Seaport's cancel() and distinguishes from the sibling tool cancel_offer. It uses specific verbs and resources ('cancel an active ENS name listing', 'submit Seaport's cancel()') and explicitly differentiates from cancel_offer for offers.

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

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

The description provides explicit usage guidance: only the original seller can cancel, and for cross-posted listings both order hashes should be passed as alsoCancel. It also directs users to cancel_offer for cancelling offers as a buyer, giving clear when-to-use and when-not-to-use advice.

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

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

Annotations indicate destructiveHint=true and idempotentHint=true. The description adds that it returns unsigned Seaport cancel() calldata, releases committed WETH, and invalidates the Seaport order. This enriches the behavioral context beyond annotations without contradiction.

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

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

The description is 5 purposeful sentences, front-loaded with the core action, then details on constraints, alternatives, and side effects. No filler or repetition.

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

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

For a tool with 3 parameters, 100% schema coverage, and no output schema, the description fully explains the return type (unsigned calldata), the prerequisite (offerer identity), and the effect (WETH release). It answers likely agent questions.

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 meaningful context: explains that walletAddress must match the original offerer, and that alsoCancel handles sibling orders like OpenSea variants, with a cost note. This goes beyond the schema's 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 cancels an active offer on an ENS name, with the verb 'cancel' and resource 'offer'. It distinguishes from the sibling 'cancel_listing' by explicitly mentioning '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?

It explicitly states who can cancel ('Only the bidder...') and when to use it (to cancel an offer). It provides specific guidance for cross-posted offers on OpenSea, requiring passing both order hashes. It also tells when not to use it by referencing the alternative 'cancel_listing'.

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

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

Annotations set readOnlyHint=true, and the description adds substantial behavioral context: it confirms the operation is read-only, details return fields (status, owner, expiry), explains special statuses (GRACE_PERIOD, PREMIUM_AUCTION), and mentions ENS character rule validation. No contradiction.

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

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

The description is dense yet efficient, covering all necessary aspects without redundancy. Each sentence serves a purpose—usage guidance, status explanation, pricing nuance—and is front-loaded with the primary action.

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 fully explains return values and their implications (status meanings, premium handling, validation). It addresses edge cases and provides complete context for an agent to correctly interpret results.

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 provides 100% coverage with description for the 'names' array. The tool description adds value by clarifying acceptable formats (with or without .eth suffix) and reiterating the max of 100, but does not introduce new parameter semantics beyond what schema already offers.

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

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

The description clearly states the verb 'Check' and resource 'availability of ENS names', specifies the source of names ('user-named or labels from enumerate_entities'), and distinguishes this from siblings like search_ens_names or get_name_details by focusing on availability status.

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

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

The description explicitly instructs NOT to feed invented names and to use enumerate_entities for verified labels, providing clear when-to-use guidance. It also explains what each status means (e.g., GRACE_PERIOD not registerable, PREMIUM_AUCTION registerable with premium) and how to interpret results.

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

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

Discloses return type (unsigned Seaport OrderComponents), next steps (sign and submit to URL), fee structure (1% seller-paid), and requirement for operator approval. No annotations contradict; description adds significant 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, front-loaded with purpose, then step-by-step explanation, fee, limitation, prerequisites, and tips. No wasted sentences.

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

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

Comprehensive for a 4-param tool with no output schema. Describes the output, usage workflow, fees, and limitations. All necessary context provided.

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 100% with clear descriptions. The priceEth description explains the fee, which is also reiterated in the description. Adds minor extra 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?

Clear verb+resource: 'List an ENS name for sale on NameWhisper's marketplace via Seaport 1.6.' Distinguished from siblings like batch_create_listings and 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?

Explicit when to use (list on NameWhisper) and when not (NW-native only; for OpenSea use their interface). Provides prerequisites (approve operator) and tips (use get_valuation, 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?

Annotations declare readOnlyHint=true. The description explains return format (list grouped by status, proper name + ENS label) and warns about model misspellings. No contradiction with annotations. Slight deduction for not explicitly stating idempotency or side effects, but read-only is adequately conveyed.

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 front-loaded with core purpose. Each paragraph adds value. Could be slightly more concise, but the length is justified by the need to clarify usage boundaries and parameter nuances. No redundant sentences.

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

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

Given only 2 parameters and no output schema, the description provides all necessary information: purpose, usage boundaries, parameter details, return format with examples, and behavioral warnings. An agent can correctly decide when and how to use this 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%. The description adds valuable context beyond the schema: for 'category', it provides specificity rules (e.g., strip qualifiers like 'available', 'famous') and corrects common mistakes. For 'filter', it explains default and typical usage. Adds meaning beyond enum values.

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 labels for finite real-world entity categories and reports availability vs registration. It provides specific examples (NBA hall of famers, Pixar films) and distinguishes from sibling tools like search_ens_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?

Extensive guidance on when to use (finite real-world categories including roles/professions) and when not (vibes/themes, ENS-native, single lookups). Explicitly names alternatives (search_ens_names, check_availability) and gives examples of proper category formulation.

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

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

Annotations are all false. The description adds valuable behavioral context: the permission model based on fuse burning, the constraint that extension cannot exceed parent expiry, and the default extension period. It does not disclose idempotency or exact error handling, but overall improves understanding.

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

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

The description is three paragraphs with a clear front-loaded purpose, followed by a constraint, caller list, and use cases. Every sentence is necessary, no fluff. Highly 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 complexity of the tool (permission model, parental expiry constraint), the description covers most key aspects. It lacks explicit behavior when requested years exceed parent expiry (error vs. truncation) and does not mention output. Still, provides sufficient context for most use cases.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining the permission implications for the name parameter (who can call based on ownership and fuses). For the years parameter, it repeats schema info.

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 extends ENS subname expiry, a specific action on a particular resource (subname in NameWrapper). It distinguishes from sibling tools like renew_ens_name by focusing on subnames and mentioning the fuse system.

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 lists who can call (parent owner always, subname owner with fuse) and provides use cases. However, it does not mention when not to use or directly compare to alternative tools (e.g., manage_fuses for fuses), leaving some room for ambiguity.

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?

Goes far beyond the readOnlyHint annotation, detailing the selection criteria (desirability, confidence, comps), valuation engine behavior (conservative, cache-first), and constraints (discount band, min confidence). Explains what is returned and how to interpret it.

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 each sentence adds value. It is well-structured with clear sections. Could be slightly more concise, but the complexity justifies the 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?

Despite no output schema, the description thoroughly explains the return fields (discount, fair-value, confidence, comps) and the tool's behavior (filters, limitations, fallback). It is complete for the tool's purpose.

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

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

While schema covers 100% of parameters, the description adds crucial context like 'minConfidence floored at MEDIUM', 'maxLength omit for no cap', and explains default values and rationale. This adds significant 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 the tool scans the ENS marketplace for undervalued names, returning ranked opportunities with discount and fair-value metrics. It distinguishes itself from sibling tools like get_valuation and search_ens_names by explicitly stating when to use which.

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 (user asks for 'best value', 'bargains', etc.) and when-not-to-use (specific collections) with alternatives (search_ens_names, sweep). Also mentions filters for narrow queries.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by detailing the data retrieved and limitations (e.g., Sybil-able scores). It does not contradict annotations.

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

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

The description is well-structured with a clear front-loaded purpose, but the technical details make it slightly lengthy. It earns most sentences, though minor redundancy exists.

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?

Without an output schema, the description compensates by listing all key returns (ENSIP-25, ERC-8004, ERC-8217, reputation). It covers the complexity comprehensively.

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 a clear description of the single parameter. The description does not add significant meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states the tool checks if an ENS name or wallet is a registered AI agent and returns specific data types. It distinguishes from siblings like search_agent_directory by focusing on reputation and binding status.

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

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

The description explains what the tool checks (registration, metadata, reputation), but does not explicitly state when to use this tool versus alternatives. It mentions reputation limitations but lacks explicit when-not guidelines.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by detailing the authentication requirement (ERC-8128) and the specific data returned (ENS name, metadata, portfolio). 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?

Two sentences plus a note, all front-loaded with essential information. No fluff, every sentence serves a purpose.

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

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

Given no parameters, readOnlyHint annotation, and no output schema, the description fully explains the tool's purpose, behavior, and expected output. It mentions return values (ENS name, metadata, portfolio) despite 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?

Input schema has no parameters, and schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline of 4 is appropriate.

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

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

The description clearly states the tool returns the authenticated identity of the calling agent, with specific details on resolving wallet address to ENS name, agent metadata, and portfolio summary. It distinguishes itself from sibling tools focused on ENS operations or marketplace actions.

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 suggests 'Call this first to confirm your identity is recognized,' providing clear context for when to use it. However, it does not mention when not to use it or specify alternatives among 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?

Annotations declare readOnlyHint=true; the description adds significant behavioral context: data validated against on-chain state, filtered for correctness, includes pricing estimates for premium status. It does not contradict annotations and provides insight into data freshness and reliability.

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 a clear opening, a bullet-like status list, and a final scope note. While comprehensive, some sentences in the scope section are slightly repetitive. Overall, it communicates efficiently.

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

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

Given the tool's complexity (9 parameters, no output schema), the description covers key return values (premium pricing estimates), explains each status's behavior, and addresses common misunderstandings (e.g., scope of 'registerable NOW'). It is thorough for the tool's purpose.

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

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

With 100% schema coverage, the description still adds value: it explains each status's meaning in detail, gives specific guidance on charType usage for digit queries, and warns about length vs. digit confusion. This goes beyond the schema's descriptions.

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

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

The description opens with a clear verb ("List") and resource ("ENS names by lifecycle window"), then provides concrete examples of questions it answers. It explicitly distinguishes itself from "search_ens_names" for pattern/price queries, providing strong sibling differentiation.

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

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

The description explicitly states when to use this tool (for lifecycle windows) and when not to (for general availability queries), names the alternative tool (search_ens_names), and even addresses potential confusion about digit queries. It provides clear boundaries and example phrasing.

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

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

Annotations set readOnlyHint=true, and the description aligns by stating it 'gets' events and returns data. Additionally, it discloses a key behavioral trait: no wash-trading judgment is made, which is not captured by annotations. This adds useful transparency beyond the structured fields.

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, no waste. Front-loaded with the core purpose, then adds filtering and return details, and ends with the critical differentiator. 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 3 parameters, no output schema, and high sibling count, the description is complete. It explains what the tool does, how to filter, what the output contains, and how it differs from related tools (wash_check). No gaps remain for an 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%, so the burden is lower. However, the description adds meaning by explaining that eventTypes filter by event type, and it also describes the return fields (name, price in ETH, addresses, timestamp) and states results are sorted by most recent first. This provides context beyond the schema, though it doesn't detail the parameters themselves.

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 gets recent ENS marketplace activity, lists the types of events it covers (sales, listings, offers, etc.), and mentions the return fields (name, price, addresses, timestamp). Explicitly distinguishes from wash_check, so purpose is specific and 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?

Gives explicit guidance: 'this is raw activity only — it makes NO wash-trading / authenticity judgment; for "is this wash trading / fake volume?" use wash_check.' This clearly tells when NOT to use it and provides an alternative, making usage guidelines excellent.

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

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

Annotations already indicate readOnlyHint=true. The description adds valuable context about special behavior (e.g., creationDate handling for Vickrey-era names, wrapped status details) and explicitly states it makes no wash-trading judgment, adding transparency beyond 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 front-loaded with purpose, then lists returned fields, and provides structured guidance per field. While lengthy, every sentence adds value for a complex tool, and there is no redundancy or extraneous 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 lack of output schema, the description comprehensively covers all returned fields and their nuances (e.g., creationDate, resolver, wrapped status). It also addresses edge cases (Vickrey-era) and cross-tool references, making it fully informative 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% with a clear parameter description. The description adds no additional information about the 'name' parameter beyond what the schema provides, so it meets the baseline but does not exceed it.

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

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

The description clearly states 'Get full details for a specific ENS name' and lists specific fields, distinguishing it from siblings like get_primary_name and wash_check by explicitly noting what it does not do (e.g., wash-trading judgment).

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: when to mention creationDate, use resolver fields instead of guessing, and notes the tool does not assess wash trading, directing to wash_check for that purpose. Also connects to bulk_set_records for resolver actions.

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 reveals that the tool verifies both reverse and forward resolution directions, and explains the condition for null return. This adds significant behavioral context beyond the readOnlyHint annotation, informing the agent about internal checks.

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 yet thorough, front-loading the core purpose and then elaborating with bidirectional verification and bullet-pointed use cases. Every sentence adds value without redundancy.

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

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

Given the complexity (bidirectional verification, null return) and lack of output schema, the description fully explains what the tool does, its internal logic, and practical use cases. It is complete for an agent to decide when to invoke this tool among many 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?

The single parameter walletAddress is fully documented in the schema (100% coverage). The description does not add additional semantics or formatting details beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: to check the primary ENS name set for a wallet address via reverse resolution. The verb 'check' and resource 'primary ENS name' are specific and distinct from sibling tools like set_primary_name or 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?

The description provides explicit use cases (verify after set_primary_name, check configuration, debug missing resolution) but does not mention alternatives or when not to use this tool. This gives clear context but lacks exclusions.

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

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

Annotations already indicate readOnlyHint=true. The description adds significant behavioral context: use of vector embeddings, return fields (similarity scores, status, marketplace data), and a critical caveat about GRACE_PERIOD names not being registerable by others. 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?

Three sentences, each serving a purpose: purpose and method, output overview, and a behavioral note. No redundant or vague content. Well-structured 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?

Despite no output schema, the description fully explains return values and adds context about the indexed dataset and registration restrictions. For a search tool with good annotations and schema, 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%, so baseline is 3. The description does not add extra meaning beyond schema descriptions for the parameters themselves, but it does clarify output semantics (e.g., status types). This is adequate but not exceptional.

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 finds ENS names semantically similar to a given name using vector embeddings, and specifies the indexed dataset size (3.5M). It distinguishes from sibling tools like search_ens_names (exact/prefix) by emphasizing semantic similarity.

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

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

The description implies usage when you need alternative names based on semantics, but does not explicitly state when to use vs alternatives. It provides clear context for its function, but lacks exclusions or when-not 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?

Annotations already declare readOnlyHint=true, and the description reinforces a non-destructive read operation. It adds value by detailing the exact data returned (tool call counts, success rates, average latency), exceeding what annotations provide.

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, concise sentence that front-loads the purpose and lists key output fields. No redundant or irrelevant information; every word earns its place.

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

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

For a zero-parameter tool with readOnlyHint annotation, the description completely covers the purpose and return values. No output schema exists, but the description adequately explains what the tool returns.

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 zero parameters, so schema coverage is 100%. Description does not need to explain parameters but provides no additional semantic info. Given the absence of parameters, the baseline expectation is met.

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 retrieves usage statistics for the MCP server session, listing specific metrics (tool call counts, success rates, average latency). The verb 'Get' and resource 'usage statistics' are specific and distinguish it from sibling tools, none of which provide similar stats.

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

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

Usage is implied as a monitoring/information tool, but there is no explicit guidance on when to use it vs alternatives, nor any 'when not to use' instructions. The description lacks context for optimal 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?

The annotation readOnlyHint=true already discloses the read-only nature. The description adds value beyond annotations by detailing the outputs (confidence-rated, comparable sales, narrative) and the methodology factors (e.g., fame-scaled pricing). No contradictions, and additional context helps the agent understand behavior.

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

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

The description is three sentences (~80 words) with no filler. It front-loads the core action and then lists outputs efficiently. Every sentence adds value, making it easy to parse.

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

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

Despite lacking an output schema, the description fully explains the return values (value range, background, comparables, narrative). Combined with clear annotations and a simple input schema, the description is complete for confident agent invocation.

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

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

The input schema has 100% coverage for its single parameter 'name', describing it as 'ENS name or label to value (e.g., "coffee" or "coffee.eth")'. The description does not add new semantic details beyond this, so it meets the baseline but does not exceed.

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: 'Get a confidence-rated valuation for an ENS name.' It lists specific inputs (comparable sales, entity recognition, etc.) and outputs (estimated value range, background context, comparable sales data, narrative). This distinguishes it from sibling tools like get_name_details or check_availability, which focus on other aspects.

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 indicates 'Essential for pricing decisions,' implying the tool is used when a valuation is needed. However, it does not explicitly state when to avoid using it or compare it with alternatives (e.g., using get_name_details for basic information). A clear 'when-to-use' is provided, but no 'when-not-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?

Annotations already declare readOnlyHint=true. Description adds that it returns specific fields and explains automatic wallet selection with authentication. No contradictions. Sufficient behavioral disclosure for a read-only operation.

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

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

Two sentences in first paragraph, second paragraph adds authentication nuance. Every sentence is informative and no redundancy. Efficient and well-structured.

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

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

Tool has 3 simple params and no output schema. Description explains purpose, returned fields, and authentication. Could mention pagination (limit/offset) but not essential. Adequately complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining that wallet can be omitted with authentication (own wallet auto-used). This context goes beyond schema, improving 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?

Clearly states 'Get all ENS names owned by a wallet address' and lists returned fields (label, tags, expiry, etc.). Distinct from siblings like get_name_details (single name) and search_ens_names (search).

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 mentions use case ('portfolio analysis and wallet profiling') and authentication behavior (if authenticated and wallet omitted, uses own wallet). Does not explicitly state when not to use or list alternatives, but provides sufficient context for appropriate 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?

Beyond annotations, the description reveals behavioral traits: returns unsigned payload, requires user signing and external API submission, settles in WETH needing approval, includes 1% fee. No contradiction with annotations.

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

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

The description is well-structured with clear paragraphs, front-loads the main action, and each sentence adds value. Slightly lengthy but appropriate for the complexity, earning a 4.

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 output schema, the description fully explains the return value (unsigned OrderComponents), subsequent steps, prerequisites (WETH, approval), and fee structure. Complete for a complex 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?

With 100% schema coverage, the description adds value by explaining that ETH is treated as WETH, clarifying the wallet as buyer, and providing context for currency and expiry defaults, though schema already covers basics.

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 places an offer on a registered ENS name via Seaport 1.6, specifies the output (unsigned payload), and differentiates from sibling tools like accept_offer and cancel_offer by detailing the unique workflow and marketplace (NameWhisper).

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

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

The description provides a tip to use get_valuation first, explains the workflow (sign then submit), and notes fee structure and NW-native limitation. It lacks explicit when-not-to-use statements but offers sufficient context for appropriate 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?

ReadOnlyHint=true is matched by description stating it's a report. Discloses that it aggregates data and returns recommendations, which is beyond annotations. Slight room to mention idempotency, but satisfactory.

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 a clear first sentence, usage guidance, and enumerated returns. Slightly lengthy but each part 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?

Despite no output schema, description enumerates return fields. With only 2 simple parameters and no nested objects, it fully covers what the agent needs. Distinguishes from siblings effectively.

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

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

Schema coverage is 100%, so baseline is 3. Description doesn't add significant meaning beyond schema; the parameter 'includeRenewalPricing' is mentioned in returns but not elaborated in parameter 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 provides a one-shot management report for an ENS name, listing specific return fields. Distinguishes from get_name_details by noting the recommendation engine.

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 tells when to use (management report, health check queries) and when not to (if marketplace data needed, use get_name_details). Provides alternative and rationale.

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 explicitly warns that all fuse burning is IRREVERSIBLE, aligning with the destructiveHint annotation. It also notes that fuses expire when the name expires, adding behavioral context beyond 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 with bullet points and clear sections. It is slightly lengthy but highly informative, with no redundant 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 no output schema, the description adequately covers modes, prerequisites, and fuse types. It could briefly mention the return format for read mode, but overall it is complete for the tool's complexity.

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

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

Schema coverage is 100%, but the description adds value by explaining the meaning of each fuse and the role of the expiry parameter for burn_child_fuses. This context enriches 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 manages fuses on a wrapped ENS name, with three specific modes (read, burn_owner_fuses, burn_child_fuses). This distinguishes it from sibling tools like wrap_name or transfer_ens_name.

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

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

The description provides clear context for each mode, including prerequisites (e.g., CANNOT_UNWRAP must be burned first for burn_owner_fuses). It does not explicitly state when not to use the tool, but the mode descriptions effectively guide usage.

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

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

Annotations show no destructive hint, but description explains allowOverwrite is destructive, causing minor contradiction. However, description details transaction bundling, wrap setup, and all-or-nothing behavior, adding value beyond 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?

Well-structured paragraph with purpose first, followed by transaction details and return format. No fluff, but could be slightly shorter.

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 return format (steps array), transaction mechanics, and cost. Lacks error details beyond allowOverwrite, but sufficient for a bulk creation 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 covers 100% of parameters, so baseline is 3. Description adds context like max 50 subnames and cost, but does not significantly deepen parameter meaning beyond schema.

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

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

Description clearly states 'Bulk-create subnames under a parent ENS name' with specific verb and resource, distinguishes from siblings like bulk_set_records. Example usage ('agent001.company.eth') solidifies 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?

Explicitly designed for agent fleet deployment, gives context for bulk creation. Does not explicitly mention when not to use or alternatives, but context is clear.

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

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

Annotations declare readOnlyHint=true, but the description involves creating, registering, minting, and launching—all mutating operations. This is a direct contradiction. The description itself discloses behavioral traits well (multi-step recipe, optional steps), but the contradiction with annotations undermines trust and transparency.

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

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

The description is well-structured with a clear introductory sentence, detailed breakdown, examples, and important notes. It is somewhat long but every part serves a purpose. Slight improvements could be made to condense redundant explanations.

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 is complex with multiple parameters and steps. The description covers purpose, input constraints, return values (recommended names, recipe, transaction data), and step-by-step expectations. It explains optional behaviors (ENSIP-25 binding condition) and the final launch step. Absence of output schema is partially compensated by describing what is returned.

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 baseline is 3. The description does not add significant meaning beyond schema parameter descriptions; it focuses on the overall flow rather than per-parameter semantics. It adds context like the meaning of agentRegistry but the schema already describes parameters adequately.

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: 'Provision a complete ENS identity for an AI agent in one call.' It specifies the output (recommended names, registration recipe, transaction data) and distinguishes itself by offering a multi-step recipe that avoids manual combination of other tools.

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

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

The description explains when to use this tool (for complete agent identity provisioning) and provides context about optional steps (agentRegistry, ERC-8004 binding, launch). It cautions the calling AI must execute all steps. However, it does not explicitly state when alternative tools (e.g., register_agent, set_ens_records) should be used instead.

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

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

Annotations indicate destructiveHint=true. The description adds significant behavioral context: returns a registration recipe with transactions, requires commit and 60s wait for available names; searches multiple marketplaces and returns CHOOSE_LISTING for multiple listings. 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 efficiently structured: first sentence states purpose, followed by separate paragraphs for available and listed names. No redundant information; each 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?

Despite no output schema, the description explains return values adequately (registration recipe, CHOOSE_LISTING status, buy transaction). Covers edge cases like multiple listings, deprecated parameter, and auto-detection override.

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%, parameter descriptions are detailed with defaults, min/max, enums, and deprecation notice. The description adds meaning beyond schema by explaining the auto-detection logic and the CHOOSE_LISTING workflow.

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 purchases an ENS name, distinguishing between buying listed names and registering available ones. It uses specific verbs and resources, and is distinct from sibling tools like check_availability and 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?

The description provides clear guidance on when to use auto-detection vs specifying action, and how to handle multiple listings (CHOOSE_LISTING status). However, it does not explicitly compare to alternative tools or state when not to use 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?

The description adds behavioral context beyond the annotations: it explains the tool modifies ENS Registry ownership, is idempotent (implicitly from 'sync'), and notes that after reclaiming the resolver may need to be set. This complements the destructiveHint=true and idempotentHint=true annotations without contradiction.

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

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

The description is five sentences, well-structured with bullet points for use cases. Every sentence adds value, and there is no wasteful or repetitive content. It is appropriately 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?

For a simple mutation tool with no output schema, the description covers prerequisites, use cases, and post-conditions (resolver may need setting). It lacks explicit mention of failure conditions or return value, but given the idempotent and destructive hints, this is adequate for selection and invocation.

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

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

Schema coverage is 100% with descriptions for both parameters. The description only adds prerequisite context (must own token) which is partially covered by schema descriptions. It does not significantly enhance understanding beyond what the schema provides, so a baseline 3 is appropriate.

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

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

The description clearly states the verb 'reclaim' and the resource 'ENS Registry ownership of a .eth name', explaining it syncs the ENS Registry owner to match the BaseRegistrar token owner. It also lists specific use cases (direct transfer, out of sync, recovery) that distinguish it from sibling tools like transfer_ens_name or wrap_name.

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

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

The description explicitly lists when to use the tool (three specific scenarios), and states the prerequisite that the caller must own the BaseRegistrar ERC-721 token. It does not explicitly say when not to use it, but the use cases are clear enough for an AI agent to decide.

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 key behavioral traits beyond annotations: it returns a ready-to-sign transaction, explains the default and direct routes, states the prerequisite of owning the name, and warns that the identity is not verifiable until a subsequent record is on-chain. No contradiction with annotations.

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

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

The description is well-structured with paragraphs and a bolded important note. Every sentence provides necessary information, though it could be slightly more concise 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 (4 parameters, no output schema), the description covers all essential context: the multi-step registration process, route options, prerequisites, post-requisites, and default behavior. No critical information is missing.

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

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

With 100% schema description coverage, the description still adds significant value: it explains the meaning and impact of the route enum, the default behavior of agentURI, and the constraint on walletAddress for the adapter route. This goes well beyond what the schema provides.

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

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

The description clearly states the tool's purpose: 'Register an ENS name as an ERC-8004 agent identity on Ethereum mainnet.' It specifies the verb (register), resource (ENS name as agent identity), and distinguishes from siblings by mentioning ERC-8004 and the two routes. No ambiguity.

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

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

The description provides clear guidance on when to use the tool and how to proceed after confirmation, including the critical step of calling set_ens_records. However, it does not explicitly mention when not to use this tool or compare it directly with alternatives like provision_agent_identity.

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 the tool only builds an unsigned transaction (no spending), that the sign-card is the confirmation step, and that batch uses a single Multicall3 transaction. Also mentions 5% buffer on pricing. This adds critical context beyond annotations, which mark destructiveHint=true but description clarifies 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?

Description is well-structured into sections but somewhat long. Every sentence adds value, particularly the conversational flow and guidelines. Could be slightly more concise, but front-loading is effective.

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

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

Covers all relevant aspects: return type (transaction data, sign-card), pricing behavior, batch bundling, edge cases (expired/premium names), and integration with other tools. No output schema exists, so description fully compensates.

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

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

Schema coverage is 100% with descriptions. Description adds value by explaining years is deprecated, giving examples for duration (1 day, 7 days, etc.), stating default 365 days, and clarifying names can be string or array. This goes 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 renews an ENS name or batch of names and returns transaction data. It distinguishes from registration by noting simplicity and no commit/reveal. The verb 'renew' and resource 'ENS name' are 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?

Extensive guidelines: when to call immediately (specific names given) vs when to first call get_wallet_portfolio (open-ended requests). Includes instructions to ignore expired/premium names in batch and not to ask duration first. Explicitly names alternative tool and conversational flow.

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

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

Annotations already indicate readOnlyHint=true. Description adds that it queries a live registry via 8004scan with 110,000+ agents indexed across 50+ chains, providing useful behavioral context beyond the annotation. 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?

Concise and front-loaded: first sentence states purpose, second describes return values, then bulleted examples. No unnecessary words, 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?

No output schema, but description clearly lists returned fields (agent identity, owner, reputation, protocols, verification status, links). Given the tool's moderate complexity and 5 parameters, the description is sufficient for effective 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?

Input schema covers 100% of parameters with individual descriptions. The description adds usage examples and context (e.g., 'minReputation' tied to 'top-scored agents') but does not add new semantic meaning beyond what the schema already provides. Baseline 3 due to high schema coverage.

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

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

Description clearly states 'Search the AI agent directory' with specific verb and resource. It distinguishes from sibling tools like search_ens_names and search_knowledge by focusing on agents, capabilities, protocols, and reputation. The examples further clarify the 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?

Provides explicit when-to-use: searching for registered agents. Implicitly excludes ENS names and knowledge searches, which are handled by siblings. Examples show filtering by chain, protocol, and reputation, guiding appropriate queries.

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

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

Annotations already declare readOnlyHint=true; description adds valuable context: it searches the NAME database (not real-world people), returns structured results with specific fields, and explains behavior for various query types (e.g., floor queries return real listings). 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 with clear categories, bullet-like formatting, and front-loaded purpose. Every sentence adds value—examples, exclusions, and sibling references. Not a word wasted given the tool's complexity.

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

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

With only one parameter, no output schema, and high schema coverage, the description explains return format (structured results with name, price, owner, tags, availability) and covers all query types. Completely adequate.

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 massively enriches the single parameter 'query' by listing eight query categories with concrete examples, enabling the agent to craft correct queries beyond the schema's generic description.

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

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

The description clearly states the tool searches ENS names using natural language, enumerates specific query types (filtered, concept, creative, collection, activity, availability, bulk, floor), and distinguishes itself from siblings like enumerate_entities, find_alpha, and get_expiring_names by stating what it does not do and when to use alternatives.

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

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

Explicitly tells when to use this tool vs alternatives: 'for real-world entities use enumerate_entities', 'for lifecycle-window lists use get_expiring_names', and notes find_alpha lacks collection param. No ambiguity.

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

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

Annotations already mark the tool as read-only (readOnlyHint: true). The description adds context that it uses semantic search over curated sources, which is consistent. No destructive behavior is implied. The description does not contradict annotations.

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

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

The description is concise and well-structured: a single sentence stating purpose followed by clear usage guidance in the next paragraph. Every sentence adds value, and it avoids verbosity.

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 (semantic search over multiple sources), read-only annotation, and no output schema, the description provides sufficient context: what it searches, how to use it, and what not to use it for. A minor gap is the lack of mention about data freshness or limitations, but overall it's 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?

Input schema has 100% description coverage with reasonable descriptions for all three parameters (query, limit, source). The description adds minimal extra meaning beyond what the schema provides, but it reinforces usage context. Baseline for high coverage is 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 it searches the ENS knowledge base across multiple curated sources (governance proposals, docs, blog, forum, Farcaster). It distinguishes itself from sibling tools like 'search_ens_names' by focusing on knowledge content rather than name lookups.

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 tells when to use the tool ('for any 'how does X work' / 'what is X' / 'why does ENS …' protocol-mechanics question') and provides a detailed list of example queries. Also clearly states when NOT to use it ('Do NOT use this for name valuations, market data, availability, or a specific name's live status') and directs to other tools.

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

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

Annotations already indicate idempotent and destructive behavior. The description adds that it 'Returns encoded transaction calldata ready to sign and broadcast' and that multiple records are batched into a multicall. This provides context beyond annotations without contradiction.

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

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

The description is long but well-organized into sections for each record type, with the core purpose front-loaded. Every sentence adds information, though it could be slightly more concise 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 (3 parameters, nested objects, no output schema), the description covers input formats, auto-encoding, return value (calldata), and common record keys. It addresses all necessary usage 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%, but the description adds significant value: explains auto-encoding for non-ETH addresses and contentHash CIDs/URIs, details on ENSIP-25/26 structures, and lists common text record keys. This clarifies usage 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 'Set ENS resolver records for a name you own.' and lists supported record types (address, text, contenthash, ENSIP-25, ENSIP-26). It distinguishes itself by noting it returns calldata, not executing directly. The purpose is specific and 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?

The description implies the user must own the name ('for a name you own') and provides explicit input formatting instructions ('Always pass addresses and CIDs EXACTLY as the user gave them'). However, it does not explicitly contrast with sibling 'bulk_set_records' or state when not to use 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?

The description reveals important behaviors beyond annotations: it bundles two transactions (set ETH address record + set reverse record) into a single sign-card, requires ownership and signing, and notes that setting a new primary replaces the previous one (destructive). Annotations (idempotentHint=true, destructiveHint=true) are consistent but the description adds context.

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

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

The description is well-structured with a main sentence, example, bulleted requirements, and usage workflow. It is somewhat verbose but each sentence adds value, and the key 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?

Given there is no output schema, the description sufficiently covers the tool's complexity: bundling of transactions, ownership prerequisites, single primary per address, and post-signing verification via get_primary_name. It leaves no critical gaps for the 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?

Both parameters have schema descriptions, but the description adds vital context: 'walletAddress' must be the signer, and 'name' must be owned/controlled. This clarifies the relationship between parameters and the operation, enhancing 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's purpose: 'Set the primary ENS name (reverse resolution) for a wallet address.' It provides an illustrative example and explicitly distinguishes this tool from sibling 'set_ens_records' by instructing not to call that separately, ensuring proper usage.

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 when-to-use guidance: 'When a user says "set my primary name" / "make X my primary", JUST call this tool.' It lists requirements (ownership, ETH address record pointing, only wallet owner) and warns against calling set_ens_records additionally. It also advises 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?

Beyond annotations (destructiveHint, idempotentHint), the description adds a crucial warning: 'Records on the old resolver won't be visible after switching. Set up records on the new resolver first.' This transparently discloses the destructive effect and provides mitigation advice, fully satisfying the dimension.

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

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

The description is concise with a clear structure: summary, conceptual explanation, use cases, special parameter value, and warning. Every sentence serves a purpose, and the most critical info (purpose) is front-loaded. 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 the absence of an output schema, the description provides sufficient context for an agent to invoke the tool correctly. It covers what the tool does, when to use it, and behavioral consequences. A minor gap is not describing the return type (e.g., transaction receipt), but the action-oriented context is complete enough for deterministic 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?

Input schema covers both parameters with descriptions, but the description adds value by detailing the 'public' shortcut for the resolver parameter, saving the agent from looking up the address. This extra semantic enhancement justifies a score above baseline 3.

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

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

The description starts with a clear verb+resource: 'Change the resolver contract for an ENS name.' It explains what a resolver does and lists common use cases, making the purpose unmistakable. While it doesn't explicitly differentiate from siblings, the tool's function is unique enough to be well-understood.

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

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

The description provides explicit when-to-use guidance via common use cases (migrating, custom resolver, fixing no resolver) and mentions using 'public' for the ENS Public Resolver. It lacks explicit when-not-to-use statements, but the context is adequate for correct selection among siblings.

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

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

Adds context beyond annotations: selects cheapest-first, packs into one Seaport call, skips sold orders, refunds excess, reports results. No contradictions with annotations (destructiveHint=true is appropriate for purchase).

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 paragraph with no fluff. Front-loaded purpose, then guidelines, then parameter usage, then behavior. Every sentence serves a purpose.

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

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

Covers core behavior, usage, and response. Lacks mention of error handling or empty results, but overall adequate for a complex 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% with descriptions. Description adds value by explaining how parameters interact (e.g., count and maxBudgetEth as bounds, maxPriceEth as cap) and defaults. Slightly above baseline.

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

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

The description clearly states it's for buying the cheapest N ENS names in a category/filter in one Seaport transaction. It explicitly distinguishes from batch_purchase, which is for named 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?

Explicitly states when to use (cheapest N, sweep floor, budget-bound) and when not (named names -> batch_purchase). Also explains parameter usage for cohort selection and bounds, plus limit of 20 names per run.

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 adds substantial context beyond annotations: it explains that the tool builds an unsigned transaction ('nothing happens until they click Sign'), handles wrapped and unwrapped names, requires ownership and non-expired status, and states that resolver records remain unaffected. No contradiction with annotations.

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

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

The description is long but well-structured, front-loading the core action and then providing detailed guidance. Every sentence adds value, though some repetition could be trimmed. It earns its length given 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?

The description covers prerequisites, behavior, error handling (e.g., if recipient name has no address record), and what the user sees (sign-card). While it lacks an explicit mention of the return value format, the description is otherwise complete for a tool without an output schema.

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

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

Schema coverage is 100%, and the description adds significant meaning: for 'name' it gives an example, for 'toAddress' it explains it can be an ENS name and warns against pre-resolving, and for 'fromAddress' it clarifies the signing requirement. This adds value 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 'Transfer ownership of an ENS name to another wallet' using a specific verb and resource. It distinguishes itself from siblings like 'bulk_transfer_ens_names' by focusing on a single name transfer and clarifies it only builds an unsigned transaction.

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

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

Explicit instructions are given: 'Call this tool IMMEDIATELY — as your first and only action' with examples of user requests. It warns against asking for confirmation or calling other tools first, and includes a critical recipient rule with reasoning. This fully guides when and how to use the 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?

Annotations indicate destructive behavior. Description adds that 'all fuses are cleared upon unwrapping' and describes the permanent failure condition, going beyond 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?

Two core sentences and a list of use cases. Every sentence adds value, no clutter. Front-loaded with the main action and outcome.

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 transformation, fuse clearing, failure condition, and use cases. No output schema, so return values not needed. Could mention prerequisite of being wrapped, but implied.

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. Description adds an example for 'name' and reinforces that 'owner' is the current owner, but adds limited new meaning beyond schema.

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

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

The description states 'Unwrap a .eth name from the ENS NameWrapper back to BaseRegistrar' with specific verb and resource, and distinguishes from siblings like wrap_name. It also clarifies the conversion from 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?

Three explicit use cases are listed, but no direct comparison with alternatives like manage_fuses. The failure condition (CANNOT_UNWRAP fuse burned) provides context for 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?

Despite the readOnlyHint annotation already indicating a read operation, the description adds substantial behavioral context: it explains the output structure (confidence score, label, signals, seller profile, summary), discloses the meaning of 'assessable: false' and instructs how to handle it, and explicitly warns against misrepresenting unrun checks. This goes far beyond the annotation.

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

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

The description is dense but every sentence adds value. It front-loads the core purpose, then moves to usage, output, and edge-case handling. No filler, no repetition of schema details, and the structure makes it easy to scan. The length is justified by the tool's complexity.

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

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

The tool has no output schema, so the description must explain return values and edge cases. It does so comprehensively: explains the verdict is about a specific sale, lists the returned fields, and details the 'assessable: false' scenario with instructions on how to report it. Combined with rich annotations and full schema coverage, the description completes the picture.

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

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

With schema description coverage at 100%, the baseline is 3, but the description adds crucial semantic meaning: it designates 'label' as the primary parameter, clarifies that tx_hash, buyer, seller, and price_eth are optional enrichment, and explains that tx_hash is for pre-computed scores while others are for live analysis. This role differentiation and usage priority are not in the schema.

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

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

The description opens with a specific verb+resource: 'Assess whether an ENS name's sale(s) are WASH TRADING / fake / self-dealt / manipulated volume.' It explicitly distinguishes itself from siblings by stating 'do NOT use get_name_details or get_market_activity for that' because those tools make no wash-trading judgment. This clearly identifies the tool's unique role.

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-to-use guidance: 'THE tool for any ... question — route straight here' and explicitly names alternatives that should not be used for this purpose. It also instructs on parameter usage: 'Just pass label... is enough' and states optional parameters 'never block on them or ask the user for them.' This is exemplary usage guidance.

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

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

Annotations indicate destructiveHint=true, and the description elaborates with details about irreversible fuses, the two-step process, and the list of available fuses. No contradiction; it fully discloses the behavioral traits 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?

The description is moderately long but well-structured with bullet points for fuses. Each sentence serves a purpose; however, it could be slightly more concise 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 and absence of output schema, the description adequately covers purpose, behavior, parameters, and return type (two-step recipe). It lacks exact output format but is sufficient 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 coverage is 100%, but the description adds value beyond schema: it explains the name format with an example, warns about fuses being irreversible, and clarifies the owner requirement. This enhances 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's purpose: 'Wrap an unwrapped .eth name into the ENS NameWrapper contract.' It explains the conversion from ERC-721 to ERC-1155 and lists benefits like fuse permissions and subnames, distinguishing it from siblings like unwrap_name and manage_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?

The description provides context on when to use the tool (to enable fuse permissions, protected subnames, ERC-1155 support) and mentions the two-step transaction recipe. It does not explicitly state when not to use it or name alternatives, but the context is clear.

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