Doti Protocol (.i) MCP Server

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'initiate' which implies a mutating action, but does not disclose potential side effects, irreversibility, fees, time requirements, or preconditions (e.g., ownership, balance). For a bridge operation that likely moves assets and changes state across chains, this is a significant gap.

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 a single, tightly worded sentence that front-loads the action and resource, with no filler or repetition. Every word contributes to defining the tool's purpose.

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

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

For a complex cross-chain bridging operation, the description is incomplete. It lacks information about prerequisites (e.g., domain ownership, source chain balance), the process steps, potential time delays, and what the return value is (likely a transaction hash). With no output schema and no annotations, the agent has insufficient context to invoke the tool correctly and understand consequences.

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

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

Schema description coverage is 100%, so all three parameters (domainName, ownerAddress, destinationChainId) are already documented in the schema with descriptions. The tool description itself adds no additional meaning beyond what the schema provides. Baseline of 3 is appropriate because the schema does the heavy lifting, and the description doesn't enrich 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 uses a specific verb ('Initiate'), a clear resource ('.i domain'), and a precise action ('cross-chain teleportation/bridging to another supported EVM chain via Chainlink CCIP'). This distinguishes it from siblings like transfer_domain (likely same-chain) and register_domain. No ambiguity about what the tool 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 implies cross-chain usage but does not explicitly contrast with alternatives such as transfer_domain or provide when-to-use/when-not-to-use guidance. The destinationChainId parameter hints at chain selection, but there is no explicit statement about when this tool is appropriate versus other operations. The usage context is only implied, not stated.

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 implies a read-only operation ('Check') but does not describe the return format (e.g., boolean or per-chain status) or any potential side effects. It adds some detail by specifying the scope across four chains, but this is insufficient for a tool with no output schema.

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

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

The description is a single, tightly written sentence that front-loads the action and scope. Every word contributes value, and there is no redundant or vague phrasing. It is an exemplary model of conciseness.

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

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

For a simple check tool with one parameter and no output schema, the description covers the purpose and scope but omits the return format and any prerequisites or edge cases. An agent might need to infer what the result looks like to decide next steps, so the description is adequate but not fully complete.

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

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

The input schema covers the only parameter fully, including an example ('alex' or 'alex.i'). The description adds no additional parameter semantics beyond the schema, so a baseline of 3 is appropriate given the 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 a specific verb ('Check') and resource ('a .i sovereign domain is available for registration'), and specifies the scope ('across all 4 supported chains'). It distinguishes itself from sibling tools like register_domain and estimate_registration by focusing solely on availability, which is a distinct action.

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

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

The description provides clear context that this tool checks availability for registration, implying it should be used before attempting to register. However, it does not explicitly name alternatives or give a when-not-to-use condition. The context is sufficient for most agents, but it lacks the explicit routing that would earn 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 must disclose behavioral traits. It only says 'Claim a refund', implying a state change, but does not mention side effects, permission requirements (e.g., whether the caller must match claimantAddress), irreversibility, or failure modes. The eligibility hint ('eligible') is vague and does not explain verification. This is a significant gap for a financial 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 a single sentence that front-loads the action and then provides illustrative examples in a parenthetical. Every word earns its place, with no redundancy or filler. It is compact and immediately clear.

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 the tool's simplicity (2 flat parameters, no output schema), it is a financial refund action with no annotations. The description omits critical operational details: whether the caller must be the claimant, whether the escrow must be in a refundable state, what happens on success/failure, and whether the refund is irreversible. These are essential for an agent to invoke the tool safely and 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 fully describes both parameters: escrowId as 'The escrow deposit ID to refund' and claimantAddress as 'The 0x address eligible for the escrow refund'. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline 3 for 100% schema coverage 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 states a specific verb ('Claim a refund') targeting a specific resource ('escrow deposit') and provides concrete examples of when such deposits occur (registration race collisions, expired bridging operations). This clearly distinguishes the tool from sibling tools like transfer_domain or marketplace tools, which involve different 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 clear context by giving examples of scenarios that lead to escrow deposits, which implies when the tool should be used. However, it does not explicitly state when not to use it or name alternatives, so while context is present, exclusions are missing.

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 behavioral burden. The verb 'Calculate' strongly suggests a non-mutating read-only operation, but the description does not explicitly state that no registration or bridging transaction is triggered, nor does it mention permissions, rate limits, or whether funds are moved.

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?

One sentence, front-loaded with the core action and outputs, with no filler or repetition of the tool name. Every part contributes to understanding what the tool does.

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 identifies the main cost components but does not explain the return structure, units, or whether the result is a combined total or per-network breakdown. Since there is no output schema and no annotations, this gap leaves the agent without a complete picture of the response.

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

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

Schema description coverage is 100%, so the schema already documents domainName and targetChainId, including the valid network IDs. The description's mention of '4 supported networks' adds minimal context but no parameter-level detail beyond what the schema provides.

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

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

The description uses a specific verb ('Calculate') and names concrete outputs (registration fee, escrow payment requirements, CCIP bridging costs) plus the scope (4 supported networks). This clearly distinguishes it from register_domain or bridge_domain, which actually perform actions rather than estimate costs.

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 a pre-registration or pre-bridging cost-estimation use case, but it never explicitly says when to use this tool versus register_domain or bridge_domain, nor does it state when not to use it. The usage context is inferable but not spelled out.

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. 'Fetch' implies a read-only snapshot and the metric list tells the agent what data to expect, but it doesn't disclose output shape, freshness semantics beyond 'live', or rate limits.

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

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

A single, front-loaded sentence with no filler. The verb and scope come first, followed by concrete examples of the returned metrics, making every word earn its place.

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

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

For a zero-parameter read tool, the description provides the key information: what kind of data is returned. It doesn't specify exact return formatting or units, but given the low tool complexity this is adequate.

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

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

The tool takes zero parameters and the schema is empty, so the description doesn't need to document any inputs. The no-parameter baseline of 4 applies, and nothing about parameter usage is missing.

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 ('Fetch') and resource ('live protocol metrics') and names three concrete metric categories. It clearly reads as an overview/stats tool distinct from the transactional sibling tools, though it doesn't explicitly name a differentiating sibling.

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: call this to get live protocol-level metrics. It doesn't state exclusions or alternatives, but the sibling set is entirely domain/marketplace transaction operations, making the stats use case intuitively distinct.

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 accurately signals a read-only retrieval operation and specifies exactly what data is returned. It does not mention rate limits, error conditions, or data freshness, but for a simple zero-parameter getter these omissions are minor.

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?

A single sentence that front-loads the action ('Retrieve') and resource, lists the key data types, and scopes the result to all 4 chains. No filler or redundant phrasing.

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, low-complexity tool with no output schema, the description gives enough information about what will be returned to guide correct use. It could name the specific chains or return field names, but it is not critically incomplete.

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, so the baseline is 4. The description adds relevant context about what the resulting data conveys, even though there is no parameter detail to supplement.

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 ('Retrieve') with a concrete resource: technical network specifications, Chainlink CCIP selectors, router contracts, and registry addresses for all 4 supported chains. This clearly distinguishes it from sibling tools, which focus on domain registration, resolution, and marketplace 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 intended use is implied by the tool's name and description: call it when you need chain network specifications or contract addresses. However, there is no explicit statement about when to use it over alternatives, though none of the siblings appear directly comparable.

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 behavioral burden. It does disclose a critical trait—an atomic swap of ownership for ETH—but it omits important operational details such as prerequisites (seller must be current owner, offer must still be valid), irreversibility, failure behavior, and post-acceptance effects on listings or other 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?

A single, front-loaded sentence communicates the action and key outcome without restating schema property names or repeating obvious details. Every word earns its place.

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

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

The schema covers all inputs and the description explains the core transaction, but for an on-chain, state-changing operation with no annotations and no output schema, it leaves gaps: no return value, no error conditions, and no explicit authorization model. It is adequate but not 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 baseline is 3. The description adds only the contextual framing 'your .i domain' and 'offered ETH' but does not provide additional parameter-level meaning or format guidance beyond what the schema already states.

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 ('Accept'), a specific resource ('a buyer offer on your .i domain'), and a clear outcome ('an atomic swap of ownership for the offered ETH'). This clearly distinguishes it from sibling tools like marketplace_make_offer, marketplace_cancel_offer, and marketplace_buy_domain.

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 context is clear: this tool is for accepting an existing buyer offer as a seller. It does not explicitly name when not to use it or contrast it with closely related marketplace actions, but the described scenario is unambiguous 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Browse' implies a read-only posture and 'active' discloses a status filter, but the description does not state what each returned listing contains, how results are ordered, whether pagination beyond limit exists, or whether any side effects occur. It adds network-scope context but stops short of describing the operation's actual 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?

A single compact sentence that front-loads the verb and packs in the domain type, market nature, and network scope with zero wasted words. Every element earns its place.

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

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

For a low-complexity tool (one optional parameter, no required parameters, no enums, no nested objects), the essentials are present: purpose, listing scope ('active'), and deployment context. The only material gap is that with no output schema, the description does not hint at return-field content or ordering, which is a minor omission for a simple browse operation.

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%: the single limit parameter is fully documented in the schema as 'Max number of listings to return (default 20).' The description adds no parameter-specific meaning, but at 100% coverage the schema already carries that weight, so the baseline 3 applies.

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

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

The description uses a specific verb+resource: 'Browse active .i domains listed on the decentralized secondary marketplace,' with explicit network scope ('Arbitrum One and satellite networks'). 'Browse' cleanly differentiates it from action-oriented siblings like marketplace_list_domain, marketplace_buy_domain, and marketplace_make_offer, so an agent can distinguish this read operation without inspecting any sibling schemas.

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

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

The usage context is implied: an agent should call this when it wants to see active secondary-market listings. However, the description names no alternatives or exclusions, such as 'to view a single listing's details use marketplace_get_domain_details' or 'to list your own domain use marketplace_list_domain.' The when-to-use is clear but the when-not-to-use is left entirely to inference.

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 must carry the burden of behavioral disclosure. It states 'Instantly purchase' but does not detail side effects such as ETH transfer, token transfer, or any irreversible actions. It also does not disclose required approvals or prerequisites, which is significant for a purchase transaction.

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 a single, concise sentence that front-loads the action, resource, and method. It avoids unnecessary detail, making it easy to parse and remember, with 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 (a financial purchase with ETH) and the absence of annotations and output schema, the description is incomplete. It does not explain return values, error cases, or the need for approval, which are critical for agents to handle the transaction correctly and safely.

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

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

Although schema coverage is 100% and the schema provides basic descriptions, the inclusion of 'priceInEth' as 'Optional expected purchase price for slippage protection' adds meaning beyond the schema by clarifying its purpose. The domainName and buyerAddress are self-explanatory, but the description adds context that the schema lacks, earning a high score.

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 ('Instantly purchase'), the resource (an actively listed .i domain), and the method (from the secondary marketplace using ETH). It distinguishes itself from siblings like marketplace_make_offer and marketplace_accept_offer by specifying immediate purchase, making it easy for an agent to select the right tool.

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

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

The description implies the tool is for buying a listed domain instantly, and the optional priceInEth parameter hints at slippage protection. However, it does not explicitly state when not to use it or mention alternatives like marketplace_make_offer for negotiating, which would be helpful for agents deciding between purchase and offer.

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 full burden of behavioral disclosure. It states the action and preconditions but does not mention permissions, side effects, reversibility, or what the response/error behavior looks like. For a mutation operation like cancellation, this is a significant gap.

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 a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it easy to parse and remember.

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 mutation tool with no annotations and no output schema, the description is incomplete behaviorally: it does not explain what happens on success/failure, whether cancellation is reversible, or any additional requirements. The simple 2-parameter schema covers inputs, but the operational context is insufficient for an agent to confidently call 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?

The input schema already provides descriptions for both parameters, achieving 100% schema coverage, so the baseline is 3. The description does not add parameter-level meaning beyond the schema; 'owned .i domain' loosely maps to domainName and sellerAddress but adds no syntax or format details.

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

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

The description uses a specific verb ('Cancel') with a specific resource ('marketplace listing') and adds qualifiers ('active', 'owned .i domain') that clearly distinguish it from related operations. This differentiates it from siblings like marketplace_list_domain, marketplace_cancel_offer, and marketplace_buy_domain without needing to inspect those 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 gives clear context that the tool applies only to active listings for owned .i domains, implying when to use it. However, it does not explicitly name alternatives or state when not to use it, leaving the agent to infer the boundary from sibling tool names.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose a key side effect—releasing non-custodial or escrowed funds—and constrains the action to active offers. However, it does not mention authorization requirements, reversibility, transaction effects, or what happens on failure.

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 a single, tightly worded sentence that front-loads the action and immediately states the material consequence. Every word adds value, with no filler or repetition.

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

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

For a two-parameter, no-output-schema tool, the description plus schema covers the core invocation needs. However, the absence of usage guidance and the lack of annotation coverage leave gaps around when cancellation is appropriate, who may call it, and what result to expect, especially given the financial side effect.

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

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

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds no additional parameter-level meaning beyond the schema's own descriptions of domainName and buyerAddress, 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 uses a specific verb ('Cancel'), a specific resource ('marketplace offer'), and a scope qualifier ('active'), which makes the tool's purpose clear. It is implicitly distinguished from the sibling marketplace_cancel_listing by targeting offers rather than listings, though it does not explicitly name an 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?

The description gives no explicit guidance on when to use this tool versus siblings such as marketplace_accept_offer or claim_escrow_refund. It implies only that the offer must be active, but it does not state exclusions, prerequisites, or what to do if the offer is no longer active.

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. 'Inspect' strongly implies a read-only operation, but the description does not explicitly state that it has no side effects, does not modify state, or any auth/rate-limit considerations. It does list the content returned, which is helpful, but it omits behavioral details like error handling for non-existent domains.

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 a single sentence with no filler. It front-loads the verb and resource, then lists the specific data fields the agent can expect. Every word earns its place.

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

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

For a simple 1-parameter getter with no output schema, the description adequately enumerates the return data (active listing, price history, highest offer, bids). It is not overly complex, so this level of detail is sufficient. A minor gap is not stating what happens for invalid domains, but the core information the agent needs to call the tool correctly is present.

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 full coverage (100%) for the single parameter domainName, including a type and example. The description's phrase 'any .i domain' reinforces that the parameter is the domain name but adds no new semantics beyond the schema. Baseline 3 is appropriate since the schema 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 uses the specific verb 'Inspect' with a clear resource ('marketplace status for any .i domain') and enumerates the exact data returned (active listing, price history, highest offer, bids). This distinguishes it from siblings like marketplace_browse_listings (which lists many domains) and marketplace_buy_domain (which executes a purchase).

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: call this when you need full marketplace details for a specific .i domain. However, it does not explicitly state when not to use it (e.g., for browsing many listings, use marketplace_browse_listings) or name any alternative. The scope 'any .i domain' gives some context but no direct routing.

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?

There are no annotations, so the description carries the behavioral burden. It discloses the core mutation ('list for sale') and implies an ownership prerequisite, but it does not mention side effects such as whether an existing listing is replaced, cancellation options, fees, or failure conditions.

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?

A single focused sentence with no filler. The subject, resource, venue, and pricing model are all front-loaded, making it easy to parse quickly.

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-action listing tool with well-documented parameters, the description provides enough operative context. It omits details like listing replacement behavior or return value, but nothing essential to invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description only loosely echoes priceInEth ('in ETH') and sellerAddress ('owned'), adding no new meaning beyond the schema.

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

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

The description states a specific verb and resource: 'List an owned .i domain for sale', along with the venue ('decentralized secondary marketplace') and pricing model ('fixed price in ETH'). This clearly distinguishes it from siblings like marketplace_buy_domain or marketplace_make_offer.

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

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

The intended use is clear: to list an owned domain at a fixed ETH price. It does not explicitly contrast with alternatives such as marketplace_accept_offer or marketplace_cancel_listing, but the operation is unambiguous enough for an agent to select correctly.

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 only says 'Submit an offer' and does not explain whether this is an on-chain transaction, whether funds are locked, whether the offer is binding, or what happens when it is accepted or expires.

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 a single sentence with no filler. The primary action and target are front-loaded, and every word contributes to understanding what the tool does.

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?

This is an unannotated financial/transactional tool with no output schema. The description omits important context such as what the tool returns, whether the buyer address must match the wallet making the call, and any follow-up behavior like offer acceptance or expiration.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds only 'in ETH' and '.i domain', which are already reflected in the parameter descriptions; it does not provide additional parameter-level meaning.

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 ('Submit'), a specific resource ('an offer in ETH'), and a clear target ('any registered .i domain'). This clearly separates it from sibling tools like marketplace_accept_offer or marketplace_cancel_offer.

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

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

The description implies the tool is for proposing a purchase, but it does not explicitly say when to use it versus marketplace_buy_domain or marketplace_accept_offer. There are no alternatives mentioned, so the agent must infer usage from the word 'offer'.

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 does disclose meaningful behavioral traits: registration is 'permanent', and the tool can 'generate on-chain transaction payload' rather than necessarily executing a transaction. However, it does not explain side effects, whether funds move, when payload generation happens, or what the caller receives.

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 a single sentence with minimal filler, but the 'or' clause makes it read as two competing responsibilities without clear separation. 'Sovereign' adds little functional value, and the sentence structure obscures rather than clarifies the tool's 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?

For a tool with no annotations and no output schema, the description leaves too much unexplained: when payload generation happens, what the payload contains, how targetChainId interacts with 'the 4 networks', and whether prior availability checks or deposits are needed. An agent cannot confidently determine the full call flow.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description loosely connects to domainName and targetChainId ('the 4 networks') but adds no meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Register a permanent .i sovereign domain', which clearly identifies the primary action and object. The trailing clause 'or generate on-chain transaction payload for contract execution' introduces ambiguity about whether there are two modes, but the main purpose is still 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?

No guidance is given about when to use this tool instead of related siblings like estimate_registration, check_domain_availability, or marketplace_buy_domain. The mention of 'the 4 networks' gives some context, but there are no exclusions, prerequisites, or alternative routing.

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 bears the full burden. It lists the information returned and the optional chainId filter, but does not disclose potential side effects (e.g., that it is non-mutating, requires no authentication, or error behavior for invalid inputs). The word 'resolve' implies read-only, but explicit behavioral context is limited.

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?

A single, information-dense sentence with no superfluous words. The verb and primary resource are front-loaded, and the output list is concise. Every phrase contributes to understanding the tool's function.

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 explicitly listing the output categories (identity, owner, metadata, social links, chain location). It also notes the optional chainId filter. It omits details like response format or error handling, but for a straightforward resolver with only two parameters, the description is largely sufficient.

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 both parameters (identifier and chainId) are already documented. The description adds no additional semantic meaning beyond what the schema states, satisfying the baseline for adequate handling.

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 ('Resolve') and resource ('.i web3 domain name or 0x Ethereum wallet address'), and enumerates the returned data categories (sovereign identity, owner, metadata, social links, chain location). This distinguishes it from sibling tools like register_domain or check_domain_availability, which have different purposes.

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 use case: when you need detailed identity information for a domain or wallet. It does not explicitly name alternatives or state when not to use it, but the purpose is evident and clearly distinct from siblings, providing clear context without 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly indicates this is a mutation, but it does not say whether an existing primary domain is overwritten, whether ownerAddress must authorize or own the domain, whether the change is reversible, or what the operation returns. This is a meaningful gap for a write 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 a single, front-loaded sentence with no filler or redundancy. Every word contributes to identifying the action, resource, and target, making it appropriately concise.

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

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

For a two-parameter tool with fully described parameters, the purpose is reasonably clear informats. However, with no annotations, no output schema, and no behavioral detail, an agent is left uncertain about side effects, prerequisites, and what a successful call returns, so the context is incomplete.

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%, and both parameters are already documented with useful context: domainName is a .i domain and ownerAddress is a 0x EVM owner address. The description adds little beyond a synonym ('wallet address'), so the schema is doing 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 uses a specific verb ('Set or update') and identifies a precise resource ('primary reverse resolution domain identity') tied to a wallet address. This clearly distinguishes it from read-oriented siblings like resolve_domain_identity and from registration/marketplace tools, though it does not explicitly name an 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?

The description implies when to use the tool: when a wallet's primary reverse resolution domain needs to be set or updated. However, it gives no explicit when-not-to-use guidance and does not compare with siblings such as register_domain, update_domain_profile, or resolve_domain_identity, leaving selection mostly to inference.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It communicates that a mutation occurs ('transfer') but does not mention irreversibility, prerequisite checks of the current owner, whether the caller needs to be the current owner, gas/transaction implications, or any success/failure indicators. This is a thin description for a sensitive action.

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?

A single sentence is front-loaded with the action (transfer) and resource, with no filler. Every word contributes to the meaning, and omitting excess content makes it immediately 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?

The description fails to explain the return value or outcome of the transfer (e.g., transaction hash, success confirmation) despite the absence of an output schema. It also doesn't mention preconditions like whether currentOwner must be the caller or the need for any authorization. For a mutation tool with no annotations and no output schema, this is insufficient.

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 covers all three parameters completely (100% coverage), so the description does not need to compensate. It adds no extra meaning beyond the schema descriptions, so it stays at the baseline for high 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 states a specific verb and resource: transfer sovereign ownership of a .i domain to another wallet. The word 'directly' distinguishes it from marketplace and bridge operations among the sibling tools, so an agent can tell this is a peer-to-peer ownership transfer rather than a listing or cross-chain bridge.

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 'directly to another 0x EVM wallet address' implies this tool is used when you want a privatemarket transfer versus using the marketplace or bridge tools, but it never names any alternative or explicitly states when to choose it. Usage is inferred, not spelled out.

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 of behavioral disclosure. It says 'Update' which implies mutation, but it does not disclose whether the update is partial or full replacement, whether it requires ownership verification, whether it is reversible, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap.

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 a single sentence that front-loads the action and resource, then lists the key fields. It is concise and free of filler. It could be improved by adding usage context, but as a concise statement it earns a 4.

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

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

Given the tool has 6 parameters, no annotations, no output schema, and many siblings, the description is incomplete. It does not explain the relationship between imageMode and profileImageCid, whether updates are additive or replace the entire profile, or what the response looks like. An agent would need to open the schema and guess at behavioral semantics.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds a high-level summary of what fields are updatable (social links, website URL, IPFS avatar CID) but does not add meaning beyond the schema. Baseline 3 is appropriate when the schema 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 states a specific verb ('Update') and resource ('decentralized identity profile metadata') and enumerates the fields it affects (social links, website URL, IPFS avatar CID). It is clear about what the tool does, though it does not explicitly distinguish itself from sibling tools like set_primary_domain or resolve_domain_identity. The verb and resource are specific enough that an agent can infer this is a mutation of profile metadata rather than a read or registration operation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for updating an existing domain profile, nor does it exclude cases like setting a primary domain or transferring ownership. An agent would have to infer usage from the name and schema, which is insufficient for a tool with many siblings.

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