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

With no annotations provided, the description fully carries the behavioral burden. It discloses the atomic Seaport execution steps, the 1% fee deduction, the revert condition (buyer lacks WETH/approval), and the approval prerequisites for the seller. This is exceptionally transparent for a transaction 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?

Although longer than average, every sentence adds necessary information. The description is front-loaded with the main purpose, then organized into execution details, fee implications, potential reverts, and prerequisites. No filler or redundancy.

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

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

For a complex transactional tool with no output schema, the description covers return value, execution behavior, fees, failure modes, required approvals, and references to related tools. It leaves minimal ambiguity for an agent deciding whether and how to invoke it.

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

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

Schema coverage is 100% with both parameters well-described in the schema. The description adds slight context by referencing 'offer hash' in relation to get_name_details, but does not significantly enhance understanding beyond the schema's existing property 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 specific action: 'Accept a standing offer on an ENS name you own' and immediately follows with the return type ('Returns unsigned Seaport fulfillOrder() calldata'). It distinguishes from sibling tools like make_offer, cancel_offer, and purchase_name by focusing on the accept-offer 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?

The description provides explicit prerequisites and cautionary guidance: requires approval on NameWrapper or BaseRegistrar, references approve_operator if needed, and instructs to use get_name_details to confirm the offer hash. It also warns about the buyer's WETH balance/approval causing reverts, giving clear when-to-use context.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It warns that an approved operator can move ALL names on the contract and includes a security warning. However, it does not mention transaction costs, authority requirements (e.g., only the owner may call), or reversibility details beyond the 'approved' boolean, leaving some behavioral aspects implicit.

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

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

The description is well-structured with clear sections (summary, contracts, use cases, addresses, warning) and is front-loaded with the core purpose. It is a bit long due to including contract addresses, but each section adds value and 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?

Given the absence of an output schema and the tool's state-changing nature, the description provides substantial context: it explains the scope of approval, lists applicable contracts, gives real-world use cases, and warns about risks. It could mention that this is an on-chain transaction requiring the owner's signature, but overall it is complete enough for an agent to use it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds some context around the 'contract' enum (ERC-721, ERC-1155, registry) and the meaning of 'approved', but this largely mirrors the schema. It does not introduce new parameter semantics beyond what the schema already provides, so a baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: "Approve or revoke an operator for ENS contract interactions." It clearly distinguishes this from sibling tools by explicitly naming setApprovalForAll behavior and explaining it covers all tokens, not a single one, which separates it from transfer/wrapping operations.

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 concrete common use cases (e.g., "Approve NameWrapper on BaseRegistrar before wrapping a name") that indicate when to use this tool. It does not explicitly name alternative tools or state when not to use, but the context is clear enough for an AI agent to select it appropriately.

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

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

With no annotations, the description carries the full burden. It discloses the return type (unsigned Seaport OrderComponents), the need to POST signatures to a URL, per-name error collection with partial success, and the operator approval requirement. This is rich behavioral context beyond the basic input 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?

Each sentence adds value: purpose, return type, workflow, platform scope, comparison, error handling, prerequisite. The description is well-structured and front-loaded with the core purpose, with no 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?

Despite having no output schema, the description explains the return format and the subsequent action required. It covers error handling, prerequisites, and the full workflow, making it complete for a tool of this 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%, and each parameter already has a description. The tool description does not add new parameter-level semantics beyond what the schema states, so baseline 3 applies.

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

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

The description opens with a specific verb+resource: 'Bulk-list up to 10 ENS names for sale on NameWhisper in one signing flow.' It clearly distinguishes this from the sibling create_listing by emphasizing the batch aspect and the single-signing-flow UX.

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

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

It explicitly compares to create_listing, stating 'Cheaper UX than calling create_listing in a loop (one wallet popup vs N).' It also notes 'NW-native only' and the operator approval prerequisite, giving clear guidance on when to use this tool versus alternatives.

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

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

With no annotations, the description fully discloses behavior: it picks the cheapest active listing, validates via Seaport.getOrderStatus, encodes fulfillAvailableAdvancedOrders, and sends NFTs directly to the wallet. It also covers partial failures ('skips it and refunds excess ETH') and response details (lists which succeeded/dropped). This is rich transparency for a mutation tool.

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

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

The description is front-loaded with the core action and every sentence adds value—covering validation, execution, failure semantics, cost trade-offs, and marketplace scope. No redundant filler or repetition of schema fields.

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

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

Despite no output schema, the description explains what the response contains ('lists which labels succeeded and which were dropped'), behavior on stale orders, and the NW-only limitation. For a complex batch purchase tool, it covers the key operational and edge-case context an agent needs.

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 already describes both parameters with 100% coverage, but the description adds operational meaning: 'For each name, picks the cheapest active NW listing' clarifies how the names array is processed, and 'receives all purchased names' clarifies the wallet's role. This goes slightly beyond schema documentation.

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+scope: 'Buy up to 20 NameWhisper-listed ENS names in a single Seaport transaction.' This clearly distinguishes batch_purchase from sibling purchase_name (single name) and sweep (a different batch strategy). The purpose is explicit 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?

Provides explicit when-to-use guidance: 'Cheaper per name than individual buys (gas is amortized). For a single name, use purchase_name.' It also gives a clear exclusion: 'NW-only: this tool ignores listings posted exclusively to Grails / OpenSea.' These conditions help the agent decide between this and alternatives.

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

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

With no annotations, the description carries full burden and does an excellent job. It discloses the two-transaction flow, the 60-second wait, excess ETH refund, per-name secrets for front-running protection, and the requirement that all names be available. This gives the agent a clear behavioral model.

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: it starts with the primary purpose, then benefits, then a clear step-by-step flow, and finally a helpful follow-up suggestion. Every sentence adds value and there is no fluff or redundancy.

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

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

For a multi-step transaction tool with no annotations and no output schema, the description covers essential context: transaction flow, wait time, refund handling, availability requirement, and next steps. It lacks explicit details on the return value or failure modes (e.g., if one name is unavailable), but the provided info is quite comprehensive.

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 all parameters well-described in the schema itself. The description adds minimal parameter-specific detail beyond what's in the schema; it mentions the 20-name limit (already in schema) and the flow but doesn't enhance understanding of parameters like duration or walletAddress. Hence 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 tool's purpose: 'Register multiple ENS names in bulk' with specific details on batching and transactions. It distinguishes from siblings by emphasizing the bulk nature, cost efficiency, and the two-transaction flow, making it distinct from single-name registration tools.

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

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

The description provides clear usage context: it's 'much cheaper and faster than registering names one at a time' and supports up to 20 names per batch. It also notes that all names must be available, implying a prerequisite. However, it does not explicitly compare against alternatives like batch_purchase or state when not to use this tool, so it's slightly below a 5.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It discloses that all updates are batched into a single multicall, the max batch size, and that the signer must own/manage all names. However, it does not clarify whether records are merged or fully replaced, nor what happens if any name in the batch is not owned.

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 well-structured sentences, front-loaded with the main purpose. Each sentence provides distinct value: batching mechanism, cost benefit, record types, flexibility, and constraints. There is no redundancy or 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?

The tool is complex with a nested schema, but the description covers purpose, supported record types, batching behavior, limits, and ownership requirements. The main gap is the lack of information about the return value or transaction outcome, which neither the description nor the schema addresses.

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 the useful nuance that you can set different records per name or the same records across all names, which clarifies the nameRecords structure, but it does not significantly extend the schema's already-detailed parameter documentation.

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, distinguishing it from the sibling set_ens_records which handles single names. The phrase 'bulk record editing' and the batching into resolver.multicall() make the specific scope and mechanism obvious.

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

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

It explicitly mentions 'Much cheaper than setting records one name at a time' and references set_ens_records as the alternative, providing a clear when-to-use directive. It also states the 50-name limit and the ownership requirement, which are key constraints for correct usage.

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

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

With no annotations provided, the description carries full transparency burden. It discloses automatic detection of wrapped/unwrapped names, full ownership transfer implications, the fact that resolver records are unaffected, and ownership prerequisites. This is thorough behavioral disclosure beyond the 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 well-structured with a summary, benefit statement, key capability, requirements list, warning, and follow-up note. Every section earns its place, and the formatting with bullets and headers improves scannability. It is slightly long but appropriate for a tool with complex behavior and safety implications.

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 covers what an agent needs to know: what the tool does, prerequisites, batch limits, automatic type handling, side effects (full ownership transfer, resolver records untouched), and a recommended next step. This is complete for a transaction-type tool without return values.

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

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

Schema coverage is 100%, so the baseline is 3. The description echoes parameter meanings already present in the schema (array of name+recipient pairs, fromAddress as owner). It adds a small nuance about same/different recipients, but does not introduce new syntax or details beyond the schema. Thus, it meets but does not exceed the baseline.

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

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

The description clearly states the action: 'Transfer multiple ENS names in a single transaction via Multicall3 — bulk send.' It specifies the resource (ENS names), the verb (transfer), and the batch method, distinguishing it from the single-transfer sibling tool by emphasizing 'multiple' and 'much cheaper and faster than transferring names one at a time.'

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

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

It explicitly promotes this tool over single transfers ('much cheaper and faster'), sets clear requirements for use (ownership, valid addresses, registered names), and suggests a follow-up tool ('consider using bulk_set_records'). This gives the agent concrete guidance on when to choose this tool and what conditions must hold.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that the tool returns unsigned calldata, requires the wallet to sign and submit, marks the order invalid only after mining, and blocks all marketplaces. It also reveals the atomic cancellation behavior and permission constraint.

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 a clear purpose sentence, and every subsequent sentence adds critical information: return value, signing process, effect, permission, cross-posting, and alternative. No waste; length is justified by 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?

Despite having no output schema and no annotations, the description fully covers what the tool returns, how it works, security/permission constraints, marketplace impact, and the alternative tool. It is complete for an agent to correctly select and invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description reinforces param meaning but does not add substantial new semantics beyond the schema's own detailed descriptions. The alsoCancel and walletAddress nuances are already present in the schema, and the description primarily restates them in narrative form.

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: 'Cancel an active ENS name listing by submitting Seaport's cancel() on-chain.' It clearly distinguishes from sibling tools by explicitly pointing to cancel_offer for buyer offers, and the cross-posting nuance further differentiates it from other listing operations.

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

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

Explicit guidance is provided: 'For cancelling offers you've made as a buyer, use cancel_offer instead.' It also states the precondition that only the original seller can cancel and explains the alsoCancel use case for cross-posted listings, giving clear when-to-use and when-not-to-use context.

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

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

With no annotations, the description carries full behavioral burden and delivers: it discloses the returned unsigned calldata, the invariance that only the bidder can cancel, the need to include sibling hashes for cross-posted offers, and the WETH-release effect. This is rich, non-obvious behavioral context.

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

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

Four short, purposeful sentences; front-loaded with the core purpose, followed by constraints, effects, and alternative. Every sentence earns its place without 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?

Given no output schema, the description adequately explains the return value (unsigned calldata), prerequisites, and effects. It could slightly improve by explicitly noting how the calldata should be used (e.g., signed and submitted), but for a narrow, well-scoped tool this is nearly complete.

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

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

Schema coverage is 100% with detailed descriptions for all parameters (orderHash source, alsoCancel variant handling, walletAddress match constraint). The tool description adds a bit of narrative context (e.g., 'pass BOTH order hashes...') but largely restates what the schema already documents, so it stays at the baseline for fully covered schemas.

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

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

The description uses a specific verb and resource: 'Cancel an active offer you made on an ENS name' and immediately clarifies the output ('Returns unsigned Seaport cancel() calldata'). It also distinguishes this from the sibling cancel_listing tool by naming the alternative.

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 states when to use the tool (only by the bidder/offerer), handles the OpenSea cross-post edge case with alsoCancel, and explicitly directs to cancel_listing for listings. This is strong when-to-use and alternative 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?

Without annotations, the description carries the burden and does well: it discloses the return fields (status, owner, expiry), lists valid statuses, and states that ENS character rules are validated and .eth suffix is optional. It does not describe potential limitations like network specificity or rate limits, leaving some gaps.

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

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

The description is two sentences with no filler, leading with the action and immediately providing output details and input flexibility. Every clause adds 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?

For a simple single-parameter tool, the description conveys the core action, output content, and input normalization. It stops short of any explicit read-only statement or response structure detail, but given the availability of the schema and the straightforward nature, it is sufficiently complete.

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

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

The schema covers 100% of the parameter with a clear description and examples, so the baseline is 3. The tool description adds meaningful context by mentioning that both bare labels and .eth-suffixed names are accepted and that character rules are validated, which enriches the schema's description.

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

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

The description clearly states the tool's function with a specific verb ('Check availability') and resource ('ENS names'), and distinguishes it from sibling tools like search_ens_names or get_name_details by focusing specifically on availability status and key ownership/expiry data.

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 tool is for checking availability, but does not explicitly recommend when to use it over alternatives or mention prerequisites/exclusions. Since the purpose is clear but there is no direct competition or when-not-to-use guidance, it relies on implied usage.

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

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

With no annotations provided, the description fully discloses behavior: it returns an unsigned Seaport OrderComponents payload requiring wallet signing, specifies the authenticated submission endpoint, details the 1% seller-paid fee structure, and notes operator approval requirements. It covers the entire flow and important caveats.

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

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

The description is front-loaded with the primary purpose and covers several critical operational details (signing, endpoint, fee, approvals). While it is longer than minimal, each sentence contributes meaningful information; the tips at the end are helpful rather than fluff. It is structured logically, moving from action to flow to prerequisites.

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 (Seaport, signing, orderbook submission) and the lack of an output schema, the description compensates thoroughly. It specifies the return payload, the exact submission endpoint, required approvals, and the fee structure. It also points to relevant sibling tools (get_valuation, get_name_details) for proper use. This is a complete operational guide.

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 semantic value by clarifying the fee treatment relative to priceEth, explaining that the fee is 'baked into the order as a Seaport consideration item (seller-paid, not added on top).' This goes beyond the schema's generic description of 'what the seller receives before the 1% marketplace fee.'

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: 'List an ENS name for sale on NameWhisper's marketplace via Seaport 1.6.' This clearly distinguishes the tool from sibling tools like make_offer, purchase_name, and cancel_listing. The purpose is immediately clear 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 provides explicit when-to-use and when-not-to-use guidance: 'NW-native only' and listing on OpenSea separately. It recommends prerequisite actions ('Use approve_operator if needed', 'Use get_valuation first', 'Use get_name_details to confirm...'). This is comprehensive usage direction.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses that labels are generated and spell-verified server-side, that results are grouped by status, and that each entry includes the proper name alongside the ENS label. It does not cover auth, rate limits, or edge cases, but for this tool the key behaviors are explained.

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

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

The description is longer than a typical one-liner but every sentence earns its place: it defines the tool, lists use cases, gives exclusions, and describes the return format. The use of 'USE THIS' and 'DO NOT' headers improves scanability. Slightly verbose but well-structured and front-loaded.

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

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

For a tool with 2 parameters, no output schema, and no annotations, the description covers the essential context: when to use it, what it returns, and how it differs from siblings. It could mention potential limitations (e.g., large categories, timing) but is complete enough for an agent to select and invoke correctly.

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

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

The input schema already provides 100% coverage of both parameters, including descriptions, enums, and guidance on the 'category' parameter (e.g., strip qualifiers). The tool description reinforces these with examples but does not add new semantic information beyond what the schema already states. Baseline of 3 is appropriate.

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

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

The description opens with a specific, well-defined action: 'Enumerate ENS-friendly labels for a finite real-world entity category... and report which are available vs registered.' This clearly distinguishes the tool from siblings like search_ens_names and check_availability, and the examples ('NBA hall of fame players', 'Pixar feature films') leave no ambiguity about what it does.

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

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

The description provides explicit guidance on when to use the tool ('USE THIS for queries like...'), when not to use it ('DO NOT use for vibes/themes... or ENS-native categories'), and names the alternatives ('use search_ens_names... use check_availability'). It even warns against manually enumerating names and passing them to check_availability, giving clear behavioral rules.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It clearly explains permission requirements (parent owner, subname owner with fuse burned) and a key constraint (subname expiry cannot exceed parent expiry). It doesn't cover error behavior or side effects beyond extending expiry, but it provides substantial useful 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 clear sections for definition, permissions, and use cases. Every sentence earns its place, and the core action 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 that there is no output schema, the description covers the essential context: purpose, permissions, constraint, and use cases. It is reasonably complete for a tool of this complexity, though it doesn't specify what happens if the requested years exceed parent expiry or other failure modes.

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 the parent-expiry constraint but doesn't meaningfully augment the parameter meanings beyond what the schema already provides.

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

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

The description clearly states the tool's specific action: 'Extend the expiry of an ENS subname in the NameWrapper.' The verb 'extend' and resource 'ENS subname' are specific and distinguish it from sibling tools like renew_ens_name that likely target parent names.

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

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

The description provides explicit who-can-call rules and concrete use cases, giving clear context on when to use the tool. However, it does not explicitly name sibling alternatives or state when not to use it, which would push it to a 5.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses what the tool returns (ranked opportunities with discount percentage, estimated value range, confidence rating, comparable data) and emphasizes its 'edge' as finding mispriced names. It does not explicitly state it is read-only, but 'scan' and 'returns' imply no side effects. Lacks details on data freshness or potential lag, but the confidence rating offers some behavioral context. This is solid but not exhaustive.

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

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

The description is somewhat lengthy but front-loaded with the core value proposition, then explains return fields and usage. The bolded directive is clearly separated and high-signal. Every sentence contributes useful information (what, why, when, how to filter). It could be tightened by removing the 'agent's edge' marketing language, but it is not bloated or redundant. A strong structure with minimal waste.

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

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

Given that the tool has 7 parameters and no output schema, the description is quite complete. It explains the return format (ranked opportunities with discount, value range, confidence, comparables), lists relevant filters, and gives usage context. It does not enumerate every parameter, but the schema covers those. It could mention the sort order of results (implied by 'ranked') or any pagination behavior, but for an alpha-scanner tool, this is sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by illustrating combined filters with an example ('4-letter names under 1 ETH, best value'), but it also mentions 'tags' as a filter even though the schema does not include a 'tags' parameter. This is a minor inconsistency that prevents a higher score. Overall, the schema already explains parameters well, and the description adds marginal context with a slight error.

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 with specific verb+resource: 'Scan the ENS marketplace for alpha — names listed below their comparable-sales valuation.' It distinguishes itself from sibling tools like search_ens_names and get_valuation by explaining it does both search and valuation in one call, returning ranked opportunities. This is a specific, action-oriented purpose that leaves 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?

Excellent guidance: explicitly tells when to use this tool instead of alternatives: 'Use this instead of search_ens_names + repeated get_valuation when the user asks for "best value", "best buy", "cheapest good name", "undervalued", "bargains", or any ranked-by-value query across multiple listings.' It also mentions 'Pair with get_valuation for deep analysis, then purchase_name to execute.' This gives clear context and 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?

With no annotations, the description carries the burden and provides useful behavioral details: it explains the ENSIP-25 verification mechanism (reads text records from the resolver) and notes the live mainnet contract deployment date for ERC-8004. It does not explicitly state it is read-only, but 'check' and 'returns' imply a non-mutating operation.

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

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

The description is well-structured and front-loaded with the core purpose in the first sentence. It contains some redundancy in the separate paragraphs for ENSIP-25 and ERC-8004, but each sentence adds useful detail without being excessively verbose.

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 adequately enumerates all return types (verification, metadata, reputation) and provides technical context (live contracts, resolver reading). For a tool with one parameter and no output schema, this is fully sufficient 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?

The schema already fully describes the single parameter (nameOrWallet) with an example, and schema coverage is 100%. The description adds no additional parameter-specific meaning, so the 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 with a specific verb and resource: 'Check if an ENS name or wallet is a registered AI agent.' It enumerates the exact data returned (ENSIP-25 verification, AI metadata, ERC-8004 reputation), which distinguishes it from sibling tools like search_agent_directory or get_valuation.

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 clear context for when to use the tool (e.g., to verify agent registration and fetch reputation). However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden and reveals a key behavioral constraint: ERC-8128 signed requests are required, and it notes the effect on resolution (wallet to ENS name, metadata, portfolio). It also references setup documentation, adding useful context beyond the bare functionality.

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 efficient and front-loaded: the first sentence states the core purpose, subsequent sentences add essential context (auth requirement, setup pointer) without fluff. Every sentence contributes value, and it is appropriately sized for a zero-parameter read tool.

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

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

For a tool with no parameters and no output schema, the description is remarkably complete: it explains what the tool returns, the authentication prerequisite, and when to call it. It also links to setup details, leaving no obvious gap for the agent to invoke or 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?

The input schema is empty with zero parameters, so there is nothing to explain. The description avoids inventing parameter details, and the baseline for a no-parameter tool is 4; it doesn't need to add parameter semantics.

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: 'Returns the authenticated identity of the calling agent,' and then details what that includes (ENS name, agent metadata, portfolio summary). This clearly distinguishes the tool from the many ENS-related siblings, as it is uniquely focused on the caller's own identity.

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

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

It explicitly instructs to 'Call this first to confirm your identity is recognized,' providing clear situational guidance. It also points out the authentication prerequisite, though it doesn't contrast with alternatives or state when not to use it, but no direct substitute exists among the 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?

No annotations are provided, so the description carries the full burden. It thoroughly explains the three statuses, notes that grace/premium results are validated against on-chain state, states that renewed/released names are filtered out, and clarifies that statuses here are more reliable than the EXPIRED flag in search results. It also mentions conditional result fields (premiumEth when on-chain read landed), going beyond basic mutation/read hints.

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 bolded purpose statement, bullet-pointed statuses, and a clear alternative callout. It is front-loaded, and every sentence adds useful context (status semantics, validation, result fields, filters, alternative). No 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?

Given there is no output schema and no annotations, the description covers essential behavioral and result information (premiumUsd, premiumEth, firstYearEth), explains the reliability of statuses, and provides guidance on filtering and alternatives. It addresses the tool's complexity (9 params) comprehensively within the description itself.

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 reinforces filter support (length/charType/category/dictionary) but adds little beyond the schema's detailed parameter descriptions. It does clarify the meaning of statuses, but that info is also in the schema. No contradictions, but no significant added value.

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+scope: 'List ENS names by lifecycle window' and immediately labels itself 'THE tool for' premium, grace, and expiring names, clearly distinguishing it from the sibling search_ens_names. The final sentence explicitly separates this from pattern/price/theme 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 explicitly states when to use this tool ('which names are in premium / on Dutch auction', 'names in grace period', 'what's expiring soon / about to drop') and explicitly names the alternative: 'Use search_ens_names for pattern/price/theme queries instead.' This provides strong usage context.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals return payload fields (name, price in ETH, buyer/seller addresses, timestamp) and sorting order ('most recent first'). It does not mention pagination behavior or limit/offset handling, but the schema covers those parameters. For a read-only activity feed, this is above-average transparency.

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

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

Three sentences: purpose, filter capability, return details. No filler, front-loaded with the primary action, and each sentence adds distinct value. Perfectly sized for the tool's moderate 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 three optional parameters, no output schema, and moderate complexity. The description covers return shape, sorting, and filter support. It omits pagination behavior explicitly, but the schema defines limit/offset. For a non-mutating feed tool, this description is nearly complete; a small gap around handling edge cases (e.g., empty result sets) prevents a 5.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a summary of event types and mentions filtering, which aligns with the enum parameter, but does not go beyond the schema's detailed parameter docs. The price and address details are about return values, not parameters. Thus it meets but does not exceed the baseline.

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

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

The description opens with 'Get recent ENS marketplace activity' — a specific verb, resource, and scope. It enumerates event types (sales, listings, offers, mints, transfers, renewals, burns) and clearly distinguishes from siblings like 'get_wallet_portfolio' (portfolio-specific) or 'wash_check' (analysis tool). The purpose is unmistakable.

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 states 'Filter by event type' and lists the event scope, making it clear this is the tool for browsing recent marketplace events. It does not explicitly name alternative tools or exclusion criteria (e.g., 'for portfolio values use get_wallet_portfolio'), but the context and event list provide sufficient guidance for when this tool is appropriate.

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

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

With no annotations, the description carries the full burden. It openly discloses a nuanced behavior: creationDate is always populated and its meaning varies for Vickrey-era names (true first-creation date from legacy auction) versus on-chain registration date. It also instructs the agent to always surface creationDate, which is valuable behavioral guidance beyond the raw data.

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

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

The description is two sentences: the first concisely lists the data returned, the second explains a subtle data nuance and provides an explicit usage instruction. No words are wasted, and 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?

The description enumerates all major return categories (owner, expiry, creation date, tags, active listings with ETH/USD prices, active offers, ENSIP-25 bindings, ENSIP-26 records) and explains the creationDate edge case. With no output schema, this adequately covers what the agent needs to know about the return value.

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

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

The input schema already provides 100% coverage with a description for the single 'name' parameter. The tool description adds no additional parameter-specific semantics, so the baseline of 3 applies.

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

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

The description uses a specific verb ('get') and identifies the resource ('full details for a specific ENS name') while enumerating the exact data returned. This clearly distinguishes it from sibling tools like search_ens_names (searching) and get_valuation (valuation only).

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

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

The description clearly frames when to use the tool: to retrieve full details for a specific ENS name. It doesn't explicitly reference alternatives, but the context is unambiguous given the sibling tools. It also includes a direct instruction to always mention creationDate when answering creation/registration questions, which guides usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool returns null when no primary name is set, verifies both reverse and forward resolution, and explains why resolution may fail (missing ETH address record). This is rich, accurate context beyond what the schema offers.

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

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

The description is slightly longer than the bare minimum but well-structured with a clear opening, a detailed explanation of the verification logic, and a bulleted list of use cases. Every sentence contributes useful information, though the first two sentences could be considered overlapping.

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 single-parameter tool with no output schema, this description is exceptionally complete. It covers the return value (ENS name or null), the behavior (both-direction verification), edge cases (missing forward record), and specific use cases, leaving no significant gaps for an agent to infer.

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 parameter description already says 'Ethereum wallet address (0x...) to check reverse resolution for'. The main description adds value by explaining how the address is used in the two-way verification, but it does not introduce new parameter-specific 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's function: checking the primary ENS name for a wallet address via reverse resolution. It specifies the verb 'check', the resource 'wallet address', and the method (reverse resolution), while also distinguishing itself from related tools like set_primary_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 three explicit use cases (verify after set_primary_name, check configuration, debug missing primary name) and explains the bidirectional verification requirement. It does not explicitly name alternative tools or when-not-to-use scenarios, but the context is clear enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It describes the return data (similar names, similarity scores, marketplace data like price/owner/expiry) and the underlying approach (vector embeddings across 3.5M+ names), which gives good transparency for a read-only similarity search. It does not cover edge cases like subdomains or case sensitivity, but these are not critical for the tool's purpose.

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

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

The description is two concise sentences, front-loaded with the core action, then returns, then use case. Every sentence adds value and there is 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?

For a simple two-parameter tool with no output schema, the description sufficiently covers purpose, return data, and recommended usage scenarios. It is complete for an agent to decide when and how to invoke it.

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%, with both 'name' and 'limit' already well documented in the schema. The description adds no additional parameter-level semantics beyond what the schema provides, so the 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 finds ENS names semantically similar to a given name using vector embeddings, with a specific resource and scope. It distinguishes itself from siblings like search_ens_names by emphasizing semantic similarity and vector embeddings rather than exact matching.

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

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

The description includes a clear use case: 'Great for discovering related names for portfolio building or brand exploration.' This provides context for when to use the tool, though it does not explicitly name alternatives or state 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?

No annotations are provided, so the description must carry the full transparency burden. It discloses the output metrics but does not explicitly state that the operation is read-only or has no side effects. The read-only nature is strongly implied by 'Get' and the nature of statistics, but not made explicit.

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

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

The description is two sentences long, front-loaded with the tool's purpose, and each sentence provides useful information. No wasted words or redundant 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 zero-parameter, read-only statistics tool, the description adequately covers the return value (call counts, success rates, average latency) and scope (this session). No output schema exists, but the description explicitly lists the key metrics, making the tool's behavior clear enough for an agent to invoke correctly.

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

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

The tool has zero parameters and an empty input schema. There is no parameter burden for the description to carry, so the baseline score of 4 applies. The description appropriately focuses on what the tool returns rather than parameters.

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

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

The description uses a specific verb and resource: 'Get usage statistics for this MCP server session.' It clearly states what is returned (tool call counts, success rates, average latency), and this distinguishes it from the ENS-focused sibling tools, none of which relate to usage statistics.

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 context: this tool reports usage statistics for the current MCP server session. It does not explicitly mention alternatives or exclusions, but there are no competing sibling tools with similar functionality, so the use case is sufficiently 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?

No annotations are provided, so the description carries the full burden. It discloses what the tool returns (value range, background, comparables, narrative) and implies read-only behavior through 'Get'. It does not mention edge cases, data availability, or any side effects, but for a query tool this is reasonably transparent.

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

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

The description is two sentences, front-loaded with the core purpose, and efficiently lists the return components. It is somewhat dense but every clause adds value, so it earns a high but not perfect score.

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 the absence of an output schema, the description thoroughly enumerates all return values (range, background, comparables, narrative) and explains the valuation basis. It also states the primary use case, making it complete for an agent to understand and invoke.

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

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

The schema already provides a complete description of the single 'name' parameter with 100% coverage, including an example. The description adds no additional semantic information about the parameter, so the 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 gets a confidence-rated valuation for an ENS name, with specific inputs (comparable sales, entity recognition, search interest) and outputs (value range, background, comparables, narrative). This distinguishes it from sibling tools like get_similar_names or check_availability.

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 phrase 'Essential for pricing decisions' provides clear context for when to use the tool. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusionary 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?

With no annotations, the description must carry the burden. It discloses the output fields but does not mention pagination behavior (despite limit/offset in schema) or that 'all' may require multiple calls. It also doesn't note that the wallet parameter accepts ENS names, though the schema covers this. It does clarify read-only nature implicitly via 'Get'.

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, no wasted words, front-loaded with the core action. Efficient and appropriately sized.

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 lists the return fields, which is essential. It also provides a use case. However, it omits pagination nuances and any caveats about full enumeration, leaving a slight gap for a listing 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 description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it mentions the wallet address in prose but doesn't describe limit/offset or the ENS-name alternative.

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 a specific verb and resource: 'Get all ENS names owned by a wallet address.' It also details the returned fields (label, tags, expiry, registration date, active listing/offer prices), which distinguishes it from sibling tools like search_ens_names or get_name_details by its wallet-centric scope.

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

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

Provides a clear use case: 'Useful for portfolio analysis and wallet profiling.' However, it does not explicitly contrast with alternatives or mention when not to use it, falling short of the full 5 requirement.

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

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

With no annotations, the description fully discloses key behaviors: it returns an unsigned EIP-712 payload for the caller to sign, requires WETH and an approval, includes a 1% fee, and is not cross-posted. It also explains the post-signing flow into the orderbook, providing transparency beyond a simple mutation.

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 front-loaded: the first sentence states the purpose, followed by essential return details, requirements, fee, and a practical tip. 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 tool's complexity and lack of output schema, the description adequately explains the return payload, signing process, prerequisites, and marketplace fee. It misses minor edge cases (e.g., unregistered names) but is otherwise well-rounded for an agent to invoke the tool correctly.

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

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

The input schema already describes all 5 parameters with 100% coverage, so the description adds little beyond context already captured. It does clarify that amountEth is in ETH and mentions the default currency WETH, but this mirrors schema defaults. Baseline 3 is appropriate given 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?

The description clearly states the tool places an offer (bid) on a registered ENS name via Seaport 1.6, specifying the exact action and resource. It distinguishes itself from siblings like purchase_name, create_listing, and accept_offer by focusing on the seller-side offer lifecycle.

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 a clear tip to use get_valuation first, and notes the offer is NW-native only, setting expectations. However, it does not explicitly state when not to use this tool in favor of alternatives (e.g., purchase_name for immediate acquisition), though the purpose and sibling context imply this.

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

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

With no annotations provided, the description carries the full burden. It discloses that this is a report (read-only behavior), lists what it returns, and states what it does not include (marketplace data). However, it does not explicitly use the word 'read-only' or mention any side effects, which is a minor gap given the tool name 'manage_ens_name' could imply mutation.

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

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

The description is well-structured with a clear lead sentence and bullet-point return list. It is a bit longer than necessary but every sentence contributes value, including the sibling distinction. Front-loaded with the core purpose.

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

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

For a report-style tool with 2 parameters, no output schema, and no annotations, the description thoroughly covers what the tool returns, what it does not return, and how to use it. The enumerated return categories serve as a de facto output spec, making the description complete for 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 description coverage is 100%, with both parameters (name and includeRenewalPricing) already described in the schema. The description adds minimal extra meaning beyond placing 'On-chain renewal pricing' in the return list, which implicitly connects to includeRenewalPricing. 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 tool's function as a 'One-shot management report for an ENS name' with a specific list of return items. It explicitly distinguishes itself from sibling tools like get_name_details, noting it is 'purpose-built for status/recommendation queries'.

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

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

Provides explicit when-to-use guidance: 'ONLY tool you need' for management/status/recommendation queries, and directs users away from alternatives like get_name_details + get_valuation. Also specifies when to prefer a sibling: 'use get_name_details only if you need marketplace data.'

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

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

With no annotations provided, the description fully carries the burden and does so thoroughly. It warns that all fuse burning is irreversible, states that fuses expire with the name, and explains the consequences of each fuse type, offering complete transparency about side effects.

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

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

The description is well-structured with clear mode headings and bullet lists. Each line serves a purpose, including the prominent irreversible warning. Despite its length, it earns its space by clearly organizing complex fuse rules.

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

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

The description covers all modes, parameter usage, preconditions, and irreversible consequences, leaving minimal ambiguity for an agent. The lack of an output schema is mitigated by describing read mode as 'check which fuses are currently burned'. This is highly complete for a complex tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description enriches parameter meaning by explaining the semantics of each fuse name, the role of expiry in child burns, and the difference between owner and parent fuses. This exceeds the schema's basic descriptions but could be even more detailed on edge cases.

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 an ENS name, with three explicit modes: read, burn_owner_fuses, and burn_child_fuses. This distinguishes it from sibling tools like unwrap_name or wrap_name by focusing on fuse management.

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

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

It provides clear when-to-use guidance for each mode, e.g., 'Burn fuses on a name you own' and 'As a parent, burn fuses on a subname', plus the prerequisite that CANNOT_UNWRAP must be burned first. However, it doesn't explicitly mention alternative tools or exclusions, so it falls just short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining that the tool returns transaction recipes (contract address, calldata, gas estimates) and that the wallet signs and broadcasts, plus the cost implications. This is meaningful beyond what a schema would automatically provide, though it could add more on errors or prerequisites.

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

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

The description is compact and front-loaded with the core action. Each sentence adds value: purpose, use case, capabilities, implementation, output, and cost. There is no redundant text or filler, making it highly efficient for an agent 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?

Given the tool's complexity (4 params, no output schema, no annotations), the description covers essential aspects: what it does, the use case, the return format, and the execution model (user signs/broadcasts). It does not mention error handling or specific edge cases like the allowOverwrite parameter, but those are in the schema. Overall, it is quite complete for an agent to understand the tool's behavior.

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

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

The schema has 100% description coverage for all parameters, so the baseline is 3. The description adds a small amount of extra context (e.g., examples like agent001.company.eth) but largely reiterates what the schema already states. It does not add significant new semantics over the structured 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 starts with a specific verb+resource: 'Bulk create subnames under a parent ENS name.' It clearly distinguishes this from sibling tools by emphasizing the agent fleet deployment use case and the use of ENS NameWrapper, making it unique among bulk registration or agent provisioning tools.

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

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

The description provides clear context for when to use the tool: 'Designed for agent fleet deployment,' and notes that subnames are free except for gas costs. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full guidance. This is 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?

With no annotations, the description fully carries behavioral disclosure. It reveals the output (recommended names, multi-step recipe, ready-to-sign transaction data), the mandatory final set_ens_records step, ENSIP-25/26 record details, and the explicit requirement that the calling AI must execute all steps. It also explains conditional behavior when agentRegistry is provided.

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

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

The description is well-organized: an opening purpose statement, a detailed breakdown of outputs and requirements, an important warning, and a concrete example. Every sentence contributes necessary information for a tool of this complexity, with no padding.

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 explains what to expect back (recommended names, recipe, transaction data), how inputs map to the flow, and the significance of the final step. Combined with full schema coverage of all parameters, this is complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds contextual meaning beyond the schema: purpose and budget drive name recommendations, walletAddress owns the name, and agentRegistry triggers an additional binding record. This supplements the schema without redundancy.

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 clearly states the tool provisions a complete ENS identity for an AI agent in one call, combining name suggestion, registration recipe, and transaction data. It distinguishes itself from siblings like register_agent and set_ens_records by presenting a comprehensive all-in-one 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?

The description provides clear context: use this when you need to provision an agent's ENS identity, with purpose and budget as inputs. It does not explicitly name alternatives or exclusion cases, but the 'in one call' phrasing and mandatory-step emphasis imply it is the comprehensive alternative to step-by-step tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It reveals that for available names it returns a registration recipe with contract address, ABI, instructions, and a pre-generated secret, and that the wallet signs/submits transactions with a commit-wait-register flow. It also explains the marketplace search behavior and the CHOOSE_LISTING status for multiple listings. Some gaps remain (e.g., costs, failure modes, exact return JSON), but it is notably transparent about its high-level 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 moderately long but well-organized into sections for available and listed names, making it scannable. The opening sentence captures the core purpose immediately. Each paragraph adds necessary behavioral detail (registration recipe, marketplace search, multiple-listing handling). A few sentences could be tightened, but generally every sentence contributes useful information for a complex operation.

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 (7 parameters, no annotations, no output schema), the description is remarkably complete. It covers the two operational modes, the auto-detection behavior, the multi-listing workflow, the need to re-invoke with an orderHash, and action overriding. It stops short of describing the exact return object structure (e.g., fields of CHOOSE_LISTING status), which would be expected without an output schema, but it provides enough context for an agent to use the tool correctly in most scenarios.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining how the 'action' parameter allows override, how 'orderHash' is used after a user selects from multiple listings, and that 'duration' is in days with a default of 365. It also clarifies the deprecated 'durationYears' is converted to days. This contextual information enhances the parameter semantics without merely repeating 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 states a specific verb ('Purchase') and resource ('ENS name'), and clearly distinguishes two main modes: buying a listed name or registering an available name. It differentiates from sibling tools like bulk_register or accept_offer by explaining the auto-detection flow and marketplace search. The overall purpose is unambiguous and well-scoped.

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 on when to use the tool: for purchasing an ENS name, either via marketplace listing or direct registration. It explains the two distinct paths and how to handle multiple listings (calling again with orderHash). While it doesn't explicitly name alternative tools (e.g., 'for bulk registration use bulk_register'), it gives enough context for an agent to decide when this tool is appropriate, and even mentions overrides via the 'action' parameter.

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

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

With no annotations, the description carries the full burden. It discloses the core behavior (syncing registry owner to match token owner), the caller requirement, and the potential need to set resolver afterward. It does not mention reversibility, fees, or edge-case failures, but covers the most important behavioral traits.

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: a clear one-line purpose, a bulleted list of use cases, and a short prerequisite/follow-up note. Every sentence adds value, with no redundancy or fluff. Despite being more than one sentence, it is appropriately sized for 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?

Given the absence of an output schema and annotations, the description provides sufficient context for an agent to know when to use the tool, what it does, and prerequisites. It doesn't explain return values or error conditions, but those aren't critical for a mutation tool of this simplicity. The description is adequate, though a note about on-chain effects would elevate it.

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 have clear descriptions already. The description adds context by explaining the relationship between the parameters (owner must own the BaseRegistrar token) and the purpose of the 'name' parameter, but does not introduce new semantics beyond what the schema provides. 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 opens with a specific verb+resource: 'Reclaim ENS Registry ownership of a .eth name.' It clearly distinguishes this from sibling tools like transfer_ens_name or set_resolver by focusing on the sync between ENS Registry and BaseRegistrar token ownership. The use cases further clarify exactly what it does.

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

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

Explicit 'Used when' list enumerates three specific scenarios, making it clear when to invoke this tool. It also states a prerequisite (caller must own the BaseRegistrar ERC-721 token) and a follow-up action (may need to set resolver). This provides strong guidance compared to alternatives.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool returns a ready-to-sign transaction (not signed), explains the behavioral difference between adapter and direct routes, details the agentURI default and its dependency on ENS records, and highlights the critical post-transaction requirement to call set_ens_records. It also states the identity is unverifiable until the record is on-chain and describes the ALREADY_REGISTERED edge case.

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

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

The description is well-structured and front-loaded: the first sentence states the core purpose, followed by distinct paragraphs for route handling, agentURI, and essential follow-up steps. Although lengthy, every sentence provides necessary information for a complex tool, and the use of paragraphs and capitalization (IMPORTANT) improves scannability. No wasted words.

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

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

Given the tool's complexity and lack of an output schema, the description is remarkably complete. It covers the two routes, the default agentURI mechanism, the required post-transaction action, the verification method, and the already-registered edge case. It also clarifies the transaction-signing requirement and the holder constraint. No critical usage aspect is left unexplained.

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 meaningful semantics beyond the schema: it explains the implications of 'route' (control and marketplace visibility for adapter, independent NFT for direct), specifies that walletAddress MUST be the token holder for the adapter route, and clarifies the agentURI default behavior. This enrichment justifies a score above baseline, though not a full 5 since the schema already describes each parameter.

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: 'Register an ENS name as an ERC-8004 agent identity on Ethereum mainnet. Returns a ready-to-sign transaction.' It clearly distinguishes this from siblings by detailing the two routes (adapter/direct) and the ERC-8004 identity scope, making the tool's function 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 gives clear usage context: it explains the default and alternative routes, notes that the adapter route requires the caller to be the current token holder, and mandates a follow-up call to set_ens_records. It also describes the ALREADY_REGISTERED behavior. However, it does not explicitly name alternative tools or provide 'when not to use' exclusions, so it stops short of a 5.

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

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

No annotations are provided, so the description carries full burden. It discloses key behaviors: returns transaction data rather than sending it, includes a 5% pricing buffer with refund, and bundles batch renewals into a single Multicall3 transaction. It also clarifies there is no minimum duration, which is important behavioral info.

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 and examples. Every sentence adds distinct value: simplicity, flexibility, permissions, pricing, and batch behavior. There is no redundancy with the schema.

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?

Since there is no output schema, the description adequately explains the return value: transaction data with exact pricing including a 5% buffer. It also covers batch renewal behavior and refund policy, making the tool self-sufficient for an agent to invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds practical meaning beyond the schema: it gives example durations, clarifies that 'years' is deprecated, states the default for duration, and emphasizes no minimum. This provides real usage context.

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

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

The description uses the specific verb 'Renew' with resource 'ENS name or batch of names' and states the return value (transaction data). It clearly distinguishes this from sibling registration tools like purchase_name or bulk_register by emphasizing the simple, single-transaction nature.

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 contrasts renewal with registration, noting no commit/reveal is needed. It also states anyone can renew any name and lists concrete use cases such as gifting and protecting names, giving strong guidance on when 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?

With no annotations, the description carries the full burden. It discloses the live ERC-8004 registry source, the scale (110,000+ agents, 50+ chains), and the return fields (identity, owner, reputation, protocols, verification status, links). This is strong context for a search tool, though it could add explicit read-only confirmation or rate-limit info. No contradictions.

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

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

The description is well-structured: a clear opening purpose, a data-source/return-value paragraph, and impactful examples. Every sentence earns its place—there is no fluff. Length is appropriate for 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?

Despite no output schema, the description explains return values comprehensively. It also provides context about data source, chain coverage, and example use cases. With 5 optional parameters and no annotations, this is a nearly complete picture for an agent to decide when and how to invoke the tool.

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

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

Schema coverage is 100%, and the description adds a valuable mapping layer via examples: 'trading agents on Base' maps to query+chain, 'MCP agents' maps to capabilities, 'high reputation agents' maps to minReputation. This goes beyond the schema's individual field descriptions and shows how parameters combine to fulfill natural language intents.

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 a specific action ('Search the AI agent directory') with the resource and scope ('registered agents by name, capability, protocol support, or reputation'). It distinguishes itself from siblings like search_ens_names (ENS names) and get_agent_reputation (single agent reputation) by focusing on directory-wide search with multiple filters.

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 examples give concrete usage scenarios ('trading agents on Base', 'MCP agents', 'high reputation agents') that implicitly teach when to use this tool. However, it does not explicitly mention alternatives or when not to use it, such as saying 'for a single agent's reputation, use get_agent_reputation instead.' Still, the context is clear and actionable.

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

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

No annotations exist, so the description carries the burden. It clearly conveys read-only search behavior and states the output shape (name, price, owner, tags, availability). It doesn't mention rate limits or data freshness, but it goes beyond a bare 'search' statement.

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

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

The description is front-loaded with the core purpose, then uses a scannable bullet list to enumerate query types. No redundant sentences; all content earns its place despite 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?

With no output schema, the description explains what results contain and covers all major search categories. For a single-parameter tool, this is an impressively complete spec that leaves little ambiguity about expected behavior.

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

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

Schema has 100% coverage for the single `query` parameter, so baseline is 3. The description adds valuable semantics by enumerating seven concrete query styles with examples, significantly enriching the meaning of what a query can contain.

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 searches ENS names using natural language, with a comprehensive list of query types (filtered, concept, creative, collection, activity, availability, bulk). This distinguishes it from narrower sibling tools like get_similar_names or check_availability by covering a broad natural-language search surface.

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 examples of when to use it across multiple scenarios. It doesn't explicitly say when NOT to use sibling tools, but the query-type taxonomy implies it handles a wide range of user intents, making it the default entry point for natural-language search.

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

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

No annotations are present, so the description carries the full burden. It discloses that the tool uses 'semantic search over curated ENS sources' and outlines the range of content types. It does not describe the result format or any limitations beyond the exclusion, but it gives a solid behavioral picture for a search tool.

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

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

The description is two short paragraphs: the first describes the tool's purpose and coverage, the second gives a direct usage exclusion. Every sentence adds value, and the information is front-loaded. No redundancy or padding.

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 search tool with no output schema, the description effectively explains the domain, sources, and boundaries. It covers what content is searched, what topics are included, and what to avoid. It could mention result ordering or pagination, but that is not necessary for basic use. Overall, it is complete enough for an AI agent to select and invoke the 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 description coverage is 100%; all three parameters (query, limit, source) have descriptions in the schema. The description adds marginal value by clarifying that query refers to 'what you want to know about ENS governance, protocol, ecosystem, or history,' but this largely aligns with the schema. Baseline 3 is appropriate because the schema already does the heavy lifting.

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

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

The description opens with a specific verb+resource: 'Search the ENS knowledge base.' It enumerates concrete content types (governance proposals, protocol docs, blog posts, forum discussions, Farcaster casts) and explicitly states coverage (ENSv2, resolvers, subnames, historical decisions). It also distinguishes from siblings by excluding valuations, market data, and availability checks, making the purpose unmistakable.

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

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

The description explicitly says when not to use it ('Do NOT use this for name valuations, market data, or availability checks') and directs the user to 'other tools.' It implies when to use it: for any ENS governance, protocol, or history question. It stops short of naming specific sibling tools, but the exclusion criteria are clear enough.

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

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

With no annotations, the description takes on full behavioral disclosure. It clearly states the output is transaction calldata ready to sign and broadcast, explains that multiple records are batched into a multicall for gas savings, and details ENSIP-25/26 support. It does not explicitly mention whether existing records are overwritten, but the ownership requirement and record-setting semantics are transparent enough.

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

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

The description is front-loaded with the main purpose and then details supported record types and standards. It is somewhat long due to the technical depth (ENSIP-25/26 explanations), but every section adds value and avoids fluff. The structured flow from purpose to output format is logical.

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 (multiple record types, nested objects, no output schema), the description is quite complete. It covers supported record types, batching, common keys, ENSIP standards, and how to use the returned calldata. It lacks a note on overwriting behavior, but the core functionality and prerequisites are well explained.

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

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

The input schema already has 100% coverage, and the description adds substantial meaning beyond it. It gives examples of common text keys (avatar, description, url, ai.agent), explains the ENSIP-25/26 shorthand parameters (agentRegistration, agentContext, agentEndpoints), and clarifies how records map to standards. This greatly 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 it 'Set ENS resolver records for a name you own' and specifies the output as 'encoded transaction calldata ready to sign and broadcast.' It enumerates supported record types (address, text, content hash, ENSIP-25/26) and distinguishes itself from siblings by focusing on the records-setting function for a single 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 implies usage by mentioning 'for a name you own' and requiring a walletAddress that must sign, but it does not explicitly state when to use this tool over alternatives like set_resolver or bulk_set_records. It provides context and prerequisites but lacks explicit exclusions or alternative comparisons.

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

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

With no annotations, the description carries full burden. It discloses the irreversible replacement behavior ('setting a new one replaces the previous'), permission requirements ('Only the wallet owner can set their own primary name'), and the prerequisite condition on the ENS records. It does not mention return values or gas costs, but the disclosed traits are useful and accurate.

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

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

The description is well-structured with a clear purpose statement, a helpful example, and a bullet-like list of requirements. It is slightly longer than necessary but every sentence adds value, and the conditional alternative to set_ens_records is a useful addition.

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 only 2 parameters and no output schema, so the description must cover behavior and prerequisites. It does so effectively, including the replacement side-effect and required setup. However, it does not describe the expected return value (e.g., transaction hash) which would be helpful for an agent to confirm success.

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 both parameters, so the baseline is 3. The description adds contextual meaning about the relationship between the name and wallet (ETH record must point to wallet), but does not provide new syntax or format details beyond what the schema already gives.

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

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

The description opens with a specific verb and resource: 'Set the primary ENS name (reverse resolution) for a wallet address.' This clearly distinguishes it from siblings like get_primary_name and set_ens_records by explicitly focusing on reverse resolution.

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

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

Provides explicit requirements (ownership, ETH record match, wallet owner only) and an alternative: 'If the ETH address record doesn't match, use set_ens_records first to update it.' Also warns about replacement behavior, giving the agent clear when-to and when-not-to 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It prominently warns that records on the old resolver won't be visible after switching, and explains the special 'public' shortcut. It does not mention permission requirements or return values, but the critical side effect is clearly disclosed, making it more transparent than many mutation tools.

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 structured with a lead sentence, a brief explanatory paragraph, bulleted use cases, and a warning. While it is longer than minimal, every part adds valuable context. The front-loaded definition and clear sections make it easy to scan, though it could be trimmed slightly without losing essential information.

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

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

Given the tool's simplicity (2 required parameters, no output schema, no annotations), the description covers all necessary context: what a resolver is, when to use the tool, the special 'public' value, and the crucial warning about record visibility. An agent can confidently invoke this tool based solely on the description and schema.

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

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

The input schema already describes both parameters with 100% coverage. The description adds meaning beyond the schema by explaining that 'resolver' expects a contract address and by introducing the 'public' keyword as a shorthand for a specific address. This enhances the agent's understanding of valid input 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 opens with a specific verb and resource: 'Change the resolver contract for an ENS name.' It clearly distinguishes this from sibling tools like set_ens_records by explaining that the resolver is a contract where records live. This gives a precise, unambiguous 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?

The description lists common use cases such as migrating to the latest ENS Public Resolver, pointing to a custom resolver, and fixing a name with no resolver set. This provides clear when-to-use guidance. However, it does not explicitly contrast with alternative tools (e.g., set_ens_records) or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool selects cheapest-first across NameWhisper, OpenSea, and Grails, packs into one transaction, caps at 20 names, skips orders that sold and refunds the excess, and reports the swept items and totals. This is rich, specific behavioral context beyond just 'sweep'.

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 a one-sentence definition, then moves to usage guidance, parameter explanation, and execution/response details. Every sentence is substantive with no fluff or repetition. The structure is logical and easy to scan.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description is remarkably complete. It explains how to configure the sweep, the marketplaces used, the transaction packing, the cap and continuation, the refund behavior, and the exact contents of the response (marketplace + price, total, and out-of-bound count). This is enough for an agent to know when and how to invoke it correctly.

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

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

Although the schema descriptions cover each parameter individually, the description adds meaningful synthesis by grouping parameters into cohort filters (category, q, charType, minLength, maxLength) and bounds (count, maxBudgetEth, maxPriceEth). It explains how count and maxBudgetEth interact, the count default, and the 20-name cap. This cross-parameter guidance is valuable 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 what the tool does: buys the cheapest N listed ENS names in a category or matching a filter, in one Seaport transaction. It distinguishes itself from the batch_purchase tool by explicitly contrasting 'cheapest N' vs. naming specific names, and references the sibling tool by 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?

Provides explicit when-to-use guidance: 'Use this when the user wants "the cheapest N", "sweep the floor", or "buy up to X ETH of" a cohort' and explicitly names the alternative (batch_purchase) for specific-name purchases. It also walks through how to select a cohort and bound the sweep, giving clear context for when this tool is appropriate.

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

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

With no annotations provided, the description carries the full burden of disclosure. It explicitly warns about FULL ownership transfer, recipient control (transfer, set records, let expire), and that resolver records are unaffected. It also reveals the auto-detection behavior for wrapped/unwrapped names, which is important operational 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 and front-loaded: the main purpose appears first, followed by detection logic, requirements, a warning, and a clarifying note about resolver records. Every sentence contributes meaningful information, and there is no redundancy or padding.

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, automatic behavior, and consequences of transfer, which is good. However, there is no output schema and the description does not clarify what the tool returns or whether it submits the transaction or merely builds it. This ambiguity leaves a significant gap for an agent deciding whether to call the tool and how to interpret the result.

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 already provides 100% descriptive coverage for all three parameters, including the example for 'name' and the 'must sign' note for 'fromAddress'. The description adds requirements but no new parameter-level semantics beyond what's already in the schema, so the 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 opens with a specific verb+resource: 'Transfer ownership of an ENS name to another wallet address.' It goes beyond a generic statement by explaining the auto-detection of wrapped vs. unwrapped names, and the singular focus (as opposed to bulk_transfer_ens_names) is clear.

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 Requirements section gives clear preconditions (ownership, valid addresses, registered name) and the warning clarifies what this tool should be used for versus what it does not do (e.g., doesn't affect resolver records). It doesn't explicitly name alternatives like bulk_transfer_ens_names, but the context is clear enough.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects and failure modes. It clearly states that all fuses are cleared upon unwrapping and that it will fail permanently if CANNOT_UNWRAP has been burned. This is important destructive behavior disclosed upfront. It could mention the owner requirement or the resulting token recipient, but lacks detail on the return value or gas requirements.

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

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

The description is appropriately sized: a single-sentence summary, a two-sentence technical explanation, a warning about the failure condition, and three bullet-point use cases. Each element serves a purpose without redundancy or fluff. The structure is clear and scannable.

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 and no annotations, the description covers the essential context: what the tool does, the token conversion, the effect on fuses, a permanent failure condition, and when to use it. It does not explain what happens to the unwrapped token (e.g., who receives it) or any prerequisites like ownership verification, but for a simple two-parameter tool this is near-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 description coverage is 100%, so the schema fully documents the two parameters (name, owner). The description adds minimal extra meaning: it calls 'owner' the 'current wrapped name owner' in prose, but that is already in the schema description. No additional parameter details are given, so the description does not exceed the baseline value provided 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?

The description opens with a specific action: 'Unwrap a .eth name from the ENS NameWrapper back to BaseRegistrar.' It clearly distinguishes this from related tools (e.g., wrap_name) by stating the token type conversion (ERC-1155 to ERC-721) and the effect of clearing all fuses. This is unambiguous and specific.

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 'Use cases' section provides concrete scenarios (reverting to ERC-721 for compatibility, regaining full control, moving to platforms supporting ERC-721) that clarify when to use this tool. It also implies a limitation (cannot unwrap if CANNOT_UNWRAP is burned), which serves as a condition for use. However, it does not explicitly name alternatives (e.g., wrap_name or manage_fuses) or state when not to use it beyond the burned fuse condition.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It does this well by stating the function ('Check if an ENS sale is a wash trade'), the two analysis modes, and the return payload ('a wash confidence score (0-1), a label (clean/suspicious/likely_wash), detected signals, and a human-readable summary'). It doesn't mention potential side effects or safety implications, but the operation is inherently read-only/analytical, reducing the need for such disclaimers.

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

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

The description is two sentences long, front-loaded with the main purpose, then immediately providing input-mode guidance and output details. Every sentence contributes essential information without redundancy or fluff. It is well-structured and appropriately concise for 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?

Given there is no output schema, the description compensates by clearly outlining the return values (score, label, signals, summary). It also explains the two input modes, making the tool usable. However, it could be more explicit about whether the live analysis parameters are all required together, and it doesn't mention what happens if both tx_hash and live parameters are provided. These are minor gaps but prevent a perfect score.

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

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

Schema coverage is 100%, with each parameter having a description, so the baseline is 3. The description adds meaningful semantics beyond the schema by grouping parameters into two usage modes and indicating mutual exclusivity: 'Provide either a tx_hash ... or provide label + buyer + seller + price_eth.' This clarifies how the otherwise optional parameters should be combined, which is not evident from the schema alone.

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: 'Check if an ENS sale is a wash trade.' It specifies the resource (ENS sale) and the specific analysis (wash trade detection), which is unique among sibling tools. The description also distinguishes two operational modes (pre-computed score lookup vs. live analysis), providing precise scope.

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

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

The description gives explicit usage guidance by explaining two input modes: 'Provide either a tx_hash to look up a pre-computed score, or provide label + buyer + seller + price_eth for live on-demand analysis.' It clearly tells the user what inputs to supply for each scenario. However, it doesn't explicitly mention when not to use the tool or name alternative tools, though the tool's specialized nature makes this less critical.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that wrapping converts token standards, returns a two-step transaction recipe, notes that all fuses are irreversible, and specifies ordering constraints. It does not detail exact failure modes or gas costs, but it covers the most critical behavioral traits.

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

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

The description is well-structured with a clear opening statement, bullet points for benefits and fuses, and a critical note. It is longer than some, but each section earns its place. The information is front-loaded with the purpose, and the fuse list is necessary for correct usage.

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

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

For a tool with no output schema, the description explains the return value (two-step recipe), the transformation, and the constraints. It covers prerequisites (name must be unwrapped, owner must hold the token) via schema and description. It could mention what happens if the name is already wrapped or if invalid fuses are provided, but overall it is quite complete for the 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?

Although the schema already has 100% coverage with descriptions for all three parameters, the description adds significant meaning beyond the schema. It enumerates all valid fuse values (which the schema does not provide as an enum) and explains the effect of each fuse, plus the mandatory ordering rule. This is valuable semantic information that helps the agent select and validate parameters.

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

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

The description opens with a specific verb and resource: "Wrap an unwrapped .eth name into the ENS NameWrapper contract." It clearly identifies the operation and distinguishes it from siblings like unwrap_name (which reverses this process). The details about ERC-721 to ERC-1155 conversion further clarify the exact 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?

The description provides clear context for when to use the tool: when you want to enable fuses, protected subnames, or ERC-1155 compatibility. It also includes the important usage constraint that CANNOT_UNWRAP must be burned before other fuses. However, it does not explicitly name alternatives or say when not to use it (e.g., "use unwrap_name to reverse").

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