Name Whisper — ENS Intelligence Layer

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

Annotations only declare it is destructive/non-idempotent; the description goes well beyond, disclosing atomic transfer mechanics, that the buyer needs a live WETH balance and allowance or the tx reverts, that fees are deducted from proceeds, and that a bid settles the unwrapped name. This is rich operational context the annotations do not 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?

The core purpose and return format are front-loaded in the first sentence, and the subsequent sentences carry distinct operational warnings rather than filler. It is somewhat dense across several paragraphs, but nearly 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?

With no output schema, the description compensates by explaining the returned calldata and the response's fee/amount breakdown, plus approvals and revert conditions. Nothing critical to correct invocation appears missing.

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

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

Schema coverage is 100% and both parameters are fully documented in the schema, so the baseline is 3. The description only lightly reinforces semantics ('the offer hash', 'your wallet'), adding a pointer to get_name_details rather than new syntax or format detail.

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

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

The description states a specific verb and resource ('Accept a standing offer on an ENS name you own') plus the concrete return ('unsigned Seaport fulfillOrder() calldata'). It clearly distinguishes itself from siblings like make_offer, cancel_offer, and purchase_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?

It gives explicit preconditions and named alternatives: unwrap first if the name is wrapped ('unwrap_name'), approve Seaport via 'approve_operator', and confirm the offer hash with 'get_name_details'. This is exactly the when/when-not/alternatives guidance an agent needs.

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

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

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?

Goes well beyond the annotations (readOnly=false, idempotent=false, destructive=false) by describing the exact workflow: returns unsigned Seaport OrderComponents, caller signs via EIP-712 bulk signature (SIP-6), then POSTs signed orders to a named endpoint. It also discloses partial-failure semantics (per-name errors collected, batch not aborted) and the required operator approval — rich context the annotations cannot convey.

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

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

Front-loads the core action, then layers workflow, alternative, error behavior, and prerequisite in distinct paragraphs. Slightly verbose with some overlap between the 500-item mention in prose and schema, but every paragraph carries actionable 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?

Despite no output schema, the description explains the return value (array of unsigned Seaport OrderComponents), the post-call signing/submission step, and the error-field behavior on partial failure. For a complex multi-step batch mutation, nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents listings, walletAddress, and durationSeconds. The description reinforces the 500-item cap and the per-item error-collection behavior, but adds no new syntax or format detail beyond the schema. 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?

Specific verb+resource with scope: bulk-list ENS names for sale on NameWhisper in one signing flow. It explicitly differentiates itself from the sibling create_listing by contrasting the bulk single-popup flow with a per-name loop, so an agent can choose without opening either schema.

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?

States the condition for use (bulk listing, NW-native only), names the alternative (create_listing in a loop) and why this is preferred, and gives the prerequisite (operator approval via approve_operator). It also flags that partial success is normal, which shapes how the agent should 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?

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?

Goes well beyond the destructiveHint/readOnlyHint/idempotentHint annotations by disclosing the wrapped-vs-unwrapped transaction batching model, automatic detection of token standards, ownership and registration preconditions, and the irreversible loss of ownership. It also explains secondary effects (unwrapped names keep their manager, resolver records stay put, recipients should sync the manager) that an agent could not infer from the annotations.

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

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

Front-loaded with the core action and batching rules, then requirements, then the warning. It is long but nearly every sentence carries operational information; the only mild redundancy is the irreversibility warning appearing twice (mid-paragraph and again in the WARNING block).

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 destructive, non-idempotent batch tool with no output schema and full schema coverage, the description supplies everything an agent needs: preconditions, confirmation protocol, transaction batching behavior, and follow-up tooling (bulk_set_records). Nothing material is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: toAddress accepts either a 0x address or an ENS name resolved automatically, with the explicit instruction to pass the user's input verbatim rather than resolving via get_name_details. The 20-name batch limit and per-name recipient flexibility are also restated usefully.

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

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

States a specific verb and resource ('Transfer multiple ENS names') plus the batching scope ('in one batch'), which cleanly separates it from the singular sibling transfer_ens_name. An agent can identify the operation without opening the schema.

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 prescribes the conversational flow: call get_wallet_portfolio first, present the full list, confirm the recipient, and get explicit confirmation before calling. It names the trigger phrases ('send all my names' / 'transfer my names') and states NEVER auto-transfer, which is exactly the when-to-use / when-not-to-use guidance needed.

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

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

Goes well beyond the annotations (readOnly=false, destructive=true, idempotent=true): it discloses that the tool returns unsigned calldata for the wallet to sign, that the effect is permanent order invalidation across NW/Grails/OpenSea, the authorization constraint (offerer only), and the atomic multi-cancel behavior with a max of 8 extra hashes.

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

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

Front-loads the core action and return value, then layers constraints and the sibling routing in short, dense paragraphs. No filler 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?

No output schema exists, and the description compensates by describing the returned unsigned calldata and that the result enumerates every cancelled order. For a destructive, authorization-gated mutation, nothing essential is missing.

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

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

Schema coverage is already 100%, so the baseline is 3; the description nonetheless adds operational meaning by explaining why alsoCancel exists (OpenSea variant), that it must not repeat orderHash, and that all hashes must belong to the same name.

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

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

States a specific verb+resource (cancel an active ENS name listing) and the mechanism (submitting Seaport's cancel() on-chain). It explicitly differentiates from the sibling cancel_offer by stating that offers are cancelled elsewhere.

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

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

Gives explicit when/when-not guidance: only the original seller/offerer can cancel, and buyer-side offers route to cancel_offer. It also explains the cross-posted OpenSea-variant scenario and how to handle it in one transaction.

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

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

With destructiveHint=true and idempotentHint=true already declared, the description goes well beyond the annotations: it discloses the authorization constraint (bidder only), that the output is unsigned calldata rather than a broadcast transaction, the WETH-release consequence, and that batched cancels cost barely more than one. These are exactly the behavioral facts an agent needs before invoking a destructive tool.

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

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

Four short paragraphs, front-loaded with action and return value before the caveats. Every sentence carries information, though the WETH-release paragraph is slightly more elaborate than the calling decision strictly requires.

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

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

No output schema exists, and the description compensates by describing the return ('unsigned Seaport cancel() calldata', result lists every cancelled order) plus the post-conditions. Combined with auth requirements and sibling routing, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains WHY alsoCancel exists (the signed 'opensea' variant of a cross-posted offer), restates the 8-item cap and the do-not-repeat-orderHash rule as operational advice, and ties all alsoCancel entries to the same name. It largely duplicates schema text, which keeps it short of a 5.

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

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

States a specific verb and resource ('Cancel an active offer ... on an ENS name') and immediately names the return artifact ('unsigned Seaport cancel() calldata'). It explicitly separates itself from cancel_listing and from collection-offer cancellation, so differentiation from siblings is settled in the first and last sentences.

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 when-to-use ('Only the bidder ... can cancel'), an alternative for the adjacent case ('For cancelling your own listings, use cancel_listing'), and routes collection offers off-tool. The cross-posted OpenSea scenario explains exactly when the alsoCancel path applies.

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?

Annotations mark this as a non-read-only, non-idempotent, non-destructive write, and the description adds substantial behavior beyond that: it returns an unsigned payload that the caller must sign, the exact POST endpoint, the fee mechanism (1% consideration item, seller-paid), and the operator-approval requirement. The one subtlety — the tool itself only constructs a payload rather than mutating state — is still consistent with readOnlyHint=false since a listing is being created. 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?

Front-loaded with the core action and return type, then layered with fee, scope, prerequisite, and tip sections. Every paragraph carries distinct information, though the multiple trailing notes (fee, NW-native, approval, tips) make it longer than strictly minimal — still, nothing is redundant filler.

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

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

No output schema exists, yet the description compensates by describing the return shape (Seaport OrderComponents plus EIP-712 domain/types) and the full signing-and-submission lifecycle. With four parameters at full schema coverage and the mutation path fully spelled out, an agent has everything needed to invoke and complete the flow.

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 name, priceEth, walletAddress, and durationSeconds are already fully documented in the schema. The description reinforces ownership ('Must own the name') and fee semantics but adds no syntax, format, or constraint detail beyond what the schema provides. 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?

Opens with a specific verb + resource + destination: 'List an ENS name for sale on NameWhisper's marketplace via Seaport 1.6.' This clearly distinguishes it from siblings like batch_create_listings, make_offer, and manage_ens_name, which an agent can separate without opening schemas.

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

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

Explicitly states prerequisites (approve NameWrapper/BaseRegistrar via approve_operator), recommended pre-steps (get_valuation, get_name_details), the post-signing submission flow, and an exclusion (NW-native only; list on OpenSea separately). Both when-to-use and when-not-to-use are covered with named alternatives.

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

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

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 only declare readOnlyHint=true, so the description carries the rest and does so richly: two-way ENSIP-25 verification semantics, the distinction between 'claimed' and 'verified' records, the ERC-8004/ERC-8217 resolution path, on-chain aggregation via getSummary, and the Sybil-ability caveat. This is exactly the behavioral context structured fields cannot supply.

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 paragraphs are longer than typical but each carries substance—purpose, verification mechanics, reputation model plus caveat—and the purpose is front-loaded. Slightly dense, but no sentence is filler.

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

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

With no output schema, the description must explain what comes back, and it enumerates the returned categories (ENSIP-25 verification, AI metadata, ERC-8004 identity/reputation, ERC-8217 binding status) plus the claimed-vs-verified distinction. That is complete for a single-read lookup 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% for the single parameter, so the schema already documents the ENS-name-or-wallet input. The description confirms the accepted formats implicitly but adds no parsing rules or edge-case handling beyond the schema, so the baseline 3 applies.

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

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

The opening sentence gives a specific verb+resource: 'Check if an ENS name or wallet is a registered AI agent.' It clearly differentiates this lookup from siblings like register_agent, search_agent_directory, and get_name_details by naming the exact verification/registry data it returns.

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

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

Usage is implied by the purpose (use it to look up an agent's registration and reputation), but there is no explicit when-to-use/when-not guidance or pointer to an alternative such as search_agent_directory. The reputation caveat is a warning about interpretation, not routing guidance.

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

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

Annotations already 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 only declare readOnlyHint=true, but the description adds substantial behavioral context: there is no wallet filter, results are validated against on-chain state, statuses are reliable unlike the EXPIRED flag, premium results include decay-curve estimates, and every row has an existing registration. This goes far beyond 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?

The description is long and repeats the availability caveat several times, which keeps it from a 5. However, it is front-loaded, uses bullet points effectively, and every paragraph carries routing or scoping information that helps an agent avoid a costly wrong call.

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 10 parameters, no output schema, and multiple closely related sibling tools, the description is remarkably complete. It covers status semantics, scope exclusions, parameter filling guidance, output field expectations for premium, and explicit routing rules for all likely alternative intents.

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 semantics beyond the schema by explaining how status maps to lifecycle windows, how charType should be set for digit clubs, and why length filters alone do not imply digits. It does not enumerate every parameter, but it gives strategic guidance for the ambiguous ones.

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

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

The description names a specific verb ('List'), the resource ('ENS names by lifecycle window'), and the scope ('across the WHOLE market'). It clearly distinguishes itself from get_wallet_portfolio and search_ens_names, so an agent can select it without opening either schema.

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 guidance is extremely explicit: it says when to use this tool, when not to, and which sibling to use instead. It even gives concrete failure examples like 'my names close to premium' being answered incorrectly, and routes pattern/price/theme queries to search_ens_names.

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

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

Annotations only indicate readOnlyHint, but the description goes far beyond: it explains sort order, returned fields, type-specific semantics (PREMIUM_REGISTRATION is not a secondary-market sale, SWAP has no price), and the tool's lack of wash-trading judgment. 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?

Though dense, every sentence earns its place by clarifying interpretation pitfalls rather than repeating schema content. The core purpose is front-loaded, and caveats are organized logically around event types and scoping.

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

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

With no output schema, the description still tells the agent what fields are returned, that rows are sorted most-recent-first, and how to interpret each event type. Combined with the schema for pagination and the readOnly annotation, nothing essential is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds important semantics for collection (scoping to one club vs. whole market) and for eventTypes (what each event type means), while limit and offset are adequately handled by 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?

Description uses a specific verb and resource ('Get recent ENS marketplace activity') and immediately narrows scope to exactly three event types: SALE, PREMIUM_REGISTRATION and SWAP. It explicitly excludes listings, offers, mints, transfers, renewals and burns, making it easy to distinguish from related market 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?

Gives explicit guidance on when to pass the collection parameter and warns that unscoped results represent the whole market and must not be presented as a collection's sales. It also names wash_check as the alternative when the user is asking about wash trading or fake volume.

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 only declare readOnlyHint=true. The description adds important behavioral context: pagination semantics ('summary counts the WHOLE portfolio; names is one page of totalMatching'), filtering before paging, and auth behavior via ERC-8128. 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 longer than average but well-structured: purpose, return fields, sibling differentiation, pagination, auth. It is front-loaded and each block earns its place, though status examples partly repeat the schema descriptions.

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

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

With no output schema, the description compensates by listing key returned fields and explaining pagination. It covers auth, lifecycle windows, sibling alternatives, and parameter behavior thoroughly enough for an agent to invoke the tool correctly.

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

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

Input schema already covers all four parameters at 100% with detailed descriptions, giving a baseline of 3. The description adds value by giving lifecycle-status usage examples and clarifying portfolio vs. page semantics, though some content overlaps with 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?

States a specific verb and resource: 'Get all ENS names owned by a wallet address.' It also enumerates returned fields and explicitly differentiates itself from the sibling get_expiring_names, making selection unambiguous.

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

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

Provides explicit when-to-use guidance with concrete lifecycle examples ('my names close to premium', 'my names about to expire'), and names the alternative tool it is not. It also explains the authentication behavior where omitting wallet uses the connected wallet.

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 only cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds substantial extra context: the return is an unsigned payload needing a wallet signature, the maker needs wrapped ETH plus a Seaport approval, there is a 1% fee baked in as a consideration item, the submit endpoint is authenticated, and offers are NW-native only.

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

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

Front-loaded with the core action and return shape, then flow, fees, and scope in short paragraphs. Slightly long for a five-parameter tool, but every paragraph carries distinct information (signing flow, submit endpoint, approval, fee, scope).

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

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

No output schema exists, and the description compensates by explaining exactly what is returned (unsigned Seaport OrderComponents plus EIP-712 domain/types) and what the caller must do next. With annotations covering the safety profile and the schema covering parameters, nothing material is missing.

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

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

Schema description coverage is 100%, so all five parameters (name, currency, amountEth, expiryHours, walletAddress) are already documented in the schema, including the WETH/ETH equivalence and the expiry cap. The description adds only that settlement is in WETH and that the maker needs an approval, which is behavioral rather than parameter-level detail.

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

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

States a specific verb+resource ('Place an offer (bid) on a registered ENS name') and names the mechanism (Seaport 1.6) plus the venue (NameWhisper), which distinguishes it from create_listing, accept_offer, and purchase_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?

Gives clear context: it must be followed by signing and a POST to the orderbook submit endpoint, the owner can accept/counter/decline, and it tips using get_valuation first. It does not explicitly contrast with sibling tools like create_listing or accept_offer, so it falls short of a full when/when-not statement.

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

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

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?

Far exceeds the annotation baseline (readOnlyHint=false, destructiveHint=false): it discloses that each subname needs its own signature, that records bundle into one multicall but only for caller-owned subnames, that non-owned subnames appear in recordsSkipped, that an unwrapped parent triggers a prepended wrap setup, and that creation is free except gas. This is exactly the operational detail an agent needs before invoking.

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?

Purpose is front-loaded in the first sentence, and the dense paragraphs on transaction/signature mechanics and the return shape all carry real information. It runs long, but every sentence (multicall limits, recordsSkipped, wrap prepend) earns its place; only minor tightening is possible.

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 the return value (a flat ordered steps[] array where each step is a wallet signature). Combined with the transaction-model details and full schema coverage, an agent has everything needed to call and interpret this complex mutation tool.

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

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

Schema coverage is 100%, so the parameter definitions are already complete. The description still adds meaning by explaining the runtime interaction between the owner and records fields (records are only written for subnames minted to the calling wallet), which the schema alone does not convey.

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 first sentence states a specific verb (bulk-create) and resource (subnames under a parent ENS name), and the 'agent fleet deployment' framing plus the agent001.company.eth example makes the scope immediately concrete. It is clearly distinguishable from single-name siblings like bulk_register or set_ens_records.

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

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

The description establishes a clear use context ('Designed for agent fleet deployment') and implies bulk creation of many subnames at once. However, it never names an alternative (e.g. bulk_register, provision_agent_identity, manage_ens_name) or states when NOT to use it, so the routing guidance is contextual rather than explicit.

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 flag destructive=true, idempotent=false, readOnly=false, so the mutation burden is partly covered. The description adds real behavioral context beyond that: which step is gas-free, that the registry binding is conditional on agentRegistry, that identity isn't complete until text records are on-chain, and that it returns ready-to-sign transactions rather than signing them. It doesn't spell out that ETH is actually spent or that steps are irreversible.

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

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

Front-loaded with the one-line purpose before the flow detail, and every paragraph carries routing or behavioral content. It is on the long side and repeats 'OPTIONAL/OPTIONALLY' several times, and it references launch_hosted_agent, which is not in the sibling list, adding mild noise.

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?

There is no output schema, so the description correctly takes on the return-value burden by describing the names, recipe, and transaction data it emits. For a composite tool with nested parameters it is nearly complete, though the monetary/irreversibility consequences of executing the recipe could be stated more plainly.

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 pushes above baseline by explaining the effect of agentRegistry (ENSIP-25 binding only included when provided, tracking the agent identity, default ERC-8217 transfer-with-name behavior) and by tying budgetEth to the naming/registration spend, which the schema alone does not convey.

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?

Specific verb+resource: 'Provision a complete ENS identity for an AI agent in one call.' It states the exact outputs (recommended names, a registration recipe, ready-to-sign transaction data), which sharply distinguishes it from granular siblings like register_agent, set_ens_records, and search_ens_names that each do one slice of this flow.

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 clearly frames the input contract ('Describe your agent's purpose and budget') and lays out the flow's mandatory vs optional steps, naming which siblings get invoked (register_agent, set_ens_records, launch_hosted_agent). It even warns not to block on a registry address. What's missing is an explicit statement of when NOT to use this composite tool in favor of calling the individual steps directly.

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 a non-idempotent, destructive write operation, and the description goes well beyond that: it explains the tool returns a recipe rather than executing, that the user's wallet signs and submits (commit → 60s wait → register), that multiple listings produce a CHOOSE_LISTING status requiring a second call, and that prices are searched across OpenSea/Grails. This is exactly the extra behavioral context annotations cannot convey.

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

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

Front-loads the core purpose, then uses two clearly labeled blocks for the available/listed branches and a closing note on auto-detection. Well organized and mostly earned, though the auto-detection/override sentence slightly repeats the mode explanation already given.

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

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

With no output schema, the description correctly fills the gap by describing what is returned for each branch (registration recipe with contract address/ABI/steps/secret, or marketplace price options). Combined with the safety annotations and full schema coverage, an agent has everything needed to call and interpret 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%, so the schema already defines every parameter (including enums, defaults, and the deprecated durationYears note), setting a baseline of 3. The description adds real meaning on top by explaining the orderHash round-trip (call again with the chosen hash) and the action override, which is more than the schema restates.

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

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

States a specific verb+resource (purchase an ENS name) and immediately splits it into the two concrete modes: buying a listed name from a marketplace vs registering an available name on-chain. This distinguishes it from siblings like bulk_register, batch_purchase, and renew_ens_name without the agent needing to open a schema.

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 clear when-to-use context for each mode and the auto-detection behavior, plus the 'action' override. It also documents the interactive multi-listing flow (CHOOSE_LISTING → present to user → recall with orderHash). It stops short of explicitly naming sibling alternatives for the single-name vs bulk cases, so it is strong but not exhaustive routing guidance.

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

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

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?

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?

Beyond the readOnlyHint annotation, the description discloses behavioral limitations such as not understanding real-world identities and not having collection-floor support, while also clarifying that it can still answer club floor queries. It also reveals what the response contains — 'name, price, owner, tags, and availability info' — which meaningfully informs an agent about expected results.

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

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

Although the description is long, the bulleted query-type list is compact and scannable, and the routing guidance is dense with decision-relevant information. Every section earns its place; there is no filler or repetition of schema 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?

For a free-form search tool with one parameter and no output schema, the description is unusually complete: it explains supported query categories, result contents, boundary conditions, and sibling-tool routing. An agent has enough context to select this tool correctly and to frame an effective query.

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

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

The schema defines only a single 'query' string, and the description expands its semantics considerably by enumerating natural-language query categories and concrete examples. Since schema coverage is 100%, the description is not required to document parameter basics, but it adds substantial behavioral nuance 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 opens with a specific verb and resource — 'Search ENS names using natural language' — and then enumerates the full breadth of query types it supports. It also clearly distinguishes this tool from siblings by stating what it does NOT know (real-world people, teams, brands) and where to route those queries.

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

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

The description provides explicit routing guidance: use enumerate_entities for real-world entity searches, find_alpha is unsuitable for collection floor queries, and get_expiring_names is the right choice for lifecycle-window queries. It even explains why plain pattern/length-list queries should stay with this tool, preventing common misrouting.

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?

Annotations only say destructiveHint=true, but the description adds rich behavioral context: names are swept cheapest-first across NameWhisper, OpenSea, and Grails; packed into one fulfillAvailableAdvancedOrders call; capped at 20 names; sold-out orders are skipped; excess is refunded; and NFTs are delivered directly. It also discloses the response contents, which matters given there is no output schema.

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

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

The description is longer than average but every sentence earns its place: it covers intent, usage trigger, cohort selection, bounds, transaction mechanics, cap, skip/refund behavior, and response summary. It is front-loaded with the core behavior and uses structured sub-clauses instead of 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?

For a complex financial transaction tool with 9 parameters and no output schema, the description is complete: it tells when to use it, how to select the cohort, how to bound the sweep, what happens under the hood, why it is capped, and what the response reports. No significant operational gap remains.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters work together: category/q/charType/minLength/maxLength define the cohort, count and maxBudgetEth bound the sweep, and maxPriceEth caps per-name price. It also clarifies algorithm behavior like 'keeps buying up the floor until adding the next cheapest would exceed this.'

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 action: 'buy the CHEAPEST N listed ENS names in a category/collection (or matching a filter) in ONE Seaport transaction.' It also explicitly differentiates from batch_purchase, which is used for specific names, so an agent can distinguish it from the closest sibling without inspecting schemas.

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

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

The description explicitly states when to use the tool: 'Use this when the user wants "the cheapest N", "sweep the floor", or "buy up to X ETH of" a cohort.' It also names the alternative: 'rather than naming specific names (that's batch_purchase).' This gives clear selection criteria.

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

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

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.