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 carries the full burden. It discloses a key behavioral trait—the payload is unsigned and requires the owner wallet's signature—which prevents an agent from assuming the transaction is executed. However, it does not mention whether the tool broadcasts, validates ownership, or returns any signing instructions.

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 the action and resource front-loaded, followed immediately by the critical caveat about owner signature. There is 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 simple three-parameter tool with fully documented schema, the description is nearly complete. The only gap is the lack of detail about the output payload format, but that is minor given the tool's straightforward purpose and the absence of an output schema expectation.

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 adds no parameter-level meaning beyond what the schema provides, which keeps this at the baseline 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 names a specific verb ('Prepare'), a specific resource ('.i domain'), and a specific mechanism ('CCIP cross-chain bridge transaction payload'). It is clearly distinguishable from siblings like transfer_domain because it emphasizes preparing an unsigned payload rather than executing a transfer.

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

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

The description gives clear context: use this tool when bridging a .i domain cross-chain to another supported EVM chain. It does not explicitly name alternatives or exclusions, but the cross-chain condition is sufficient to route an agent 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 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 carries the behavioral disclosure burden. It is transparent that this only prepares an unsigned payload, not a signed submission, and that a claimant wallet signature is required. It could add more detail about return format or failure conditions, but the core behavior is clearly disclosed.

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 communicate the action, the resource, the eligibility context, and a required precondition with no filler. The key operational fact that the payload is unsigned 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?

For a simple two-parameter tool with no output schema, the description is largely complete. It identifies the contract, the purpose, and the signing requirement. Minor details such as chain/network context or what the payload format is are absent but not essential for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The tool description adds only contextual framing ('eligible escrow refund', 'claimant wallet signature') rather than new parameter-specific semantics, which fits the baseline of 3 when the schema handles 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 names a specific action ('prepare an unsigned transaction payload'), a target resource ('Escrow contract'), and the purpose ('claim an eligible escrow refund'). It is clearly distinct from all sibling tools, which concern domains and marketplace operations rather than escrow claims.

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

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

The description clearly states the context in which the tool is used: preparing a refund claim for an eligible claimant. It also gives a key prerequisite, the claimant wallet signature. It does not explicitly name alternatives or when-not-to-use it, but the sibling set makes the intended use obvious.

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 well by disclosing that the tool only prepares an unsigned payload — it does not execute the transaction — and that a seller wallet signature is required afterward. This is a key safety-relevant behavior. It could go further by stating whether any on-chain state is touched or how the payload is returned, but the core non-execution and signature requirement are 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?

Two sentences, front-loaded with the action and object, and the critical signature requirement is stated immediately. No filler or redundant phrasing — every phrase contributes meaning.

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

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

For a tool with no annotations and no output schema, the description covers the essential operational context: it prepares, not executes, and requires seller signature. It doesn't explain the return format or what the caller should do with the unsigned payload (e.g., sign it externally), which could leave a small gap for an agent, but the core flow is understandable. The moderate complexity and well-documented parameters keep the gap minor.

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

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

The input schema already documents all three parameters at 100% coverage, so the description is not required to restate them. The description adds only loose context ('buyer offer', 'seller wallet') that maps onto the schema fields but provides no additional semantic detail about formats or constraints. Baseline 3 is appropriate for full 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 names a specific verb ('Prepare') and a precise resource ('unsigned atomic swap transaction payload accepting a buyer offer'), which clearly distinguishes this from sibling marketplace tools like marketplace_browse_listings or marketplace_cancel_offer. The '.i domain' scope and 'buyer offer' framing make the intent 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 clearly implies the seller-side use case: accepting a buyer offer. However, it does not explicitly state when not to use this tool or name alternatives for related actions (e.g., marketplace_make_offer for buyers, marketplace_cancel_offer for withdrawing offers). Context is clear, but no exclusions or alternative routing are provided.

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 carries the full burden, and it does well: it explains that the tool prepares an unsigned payload rather than executing a transaction, and that a buyer wallet signature is required. This gives the agent important behavioral context beyond the plain 'buy' 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?

Two compact sentences with no filler. The core action is front-loaded, and the important signature requirement is stated immediately after. Every word contributes to the tool's meaning.

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

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

For a tool with no output schema and no annotations, the description adequately explains the output concept an unsigned transaction payload and the necessary signature step. It could add more detail about return structure or failure conditions, but the description is sufficient for an agent to understand 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?

The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds general context like 'ETH value' and 'buyer wallet signature,' but it does not add substantial parameter-specific meaning 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 names a specific action and resource: preparing an unsigned payable transaction payload to purchase an actively listed .i domain from the marketplace contract. This clearly distinguishes it from siblings like marketplace_make_offer, marketplace_accept_offer, and marketplace_list_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 description gives clear context for when to use the tool: when purchasing an actively listed .i domain directly from the marketplace. It also calls out a key prerequisite, the buyer wallet signature, which helps the agent understand the workflow. It does not explicitly exclude alternatives like making an offer, but the active-listing purchase context is reasonably explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Unsigned transaction payload' and 'requires seller wallet signature' make clear that the tool does not directly perform the cancellation and that external signing is needed. It could mention ownership validation or error conditions, but the core side-effect profile is fairly 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 compact sentences with no filler. The primary action is front-loaded, and the essential prerequisite about seller signature is placed immediately after.

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?

Both required parameters are fully documented in the schema, and the description states the return outcome ('unsigned transaction payload') and a key prerequisite. It omits edge cases or failure reasons, but for tool selection and basic invocation 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?

Schema description coverage is 100%, and both parameters already have clear descriptions ('The .i domain name to delist' and 'The 0x seller address who created the listing'). The tool description adds no extra parameter detail, so the baseline score 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 and resource: 'prepare an unsigned transaction payload' to 'cancel an active marketplace listing.' This clearly distinguishes it from sibling tools like marketplace_cancel_offer and marketplace_list_domain, which target different actions.

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

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

The context establishes that this tool is for canceling an active marketplace listing, and the 'requires seller wallet signature' note implies when it is appropriate. However, it does not explicitly contrast it with alternatives such as marketplace_cancel_offer 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 carries full responsibility. It discloses a key behavioral trait: the tool only 'prepares an unsigned transaction payload,' not a direct execution. It also states the requirement for buyer wallet signature. However, it omits details about error cases, response format, or what happens after signing. Given zero annotation support, a 3 is appropriate – it provides some behavioral context but not comprehensive.

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 that states the purpose and the key prerequisite. Zero wasted words; every element adds value.

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

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

Given the low complexity (2 parameters, no output schema), the description covers the essential facts: what the tool does, that it produces an unsigned payload, and the required signature. It could specify the return format or next steps more explicitly, but the core usage is adequately covered 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% with both parameters ('domainName' and 'buyerAddress') already described. The description adds the contextual note that a buyer wallet signature is required, which loosely relates to buyerAddress but does not add new semantic meaning beyond the schema. Baseline 3 is correct when schema fully documents parameters.

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

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

The description clearly states a specific action: 'cancel an active marketplace offer.' It also specifies the output is an 'unsigned transaction payload,' which distinguishes it from sibling tools like marketplace_accept_offer (accepting) and marketplace_cancel_listing (canceling a listing). The verb and resource are 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 clear context for when to use this tool (to cancel an offer) and notes the prerequisite of the buyer's wallet signature. However, it does not explicitly mention alternative tools or when NOT to use it. The sibling list implies differentiation, but the description itself lacks explicit 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. '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?

No annotations are present, so the description carries the safety burden. It discloses a key behavioral trait: the tool only prepares an unsigned transaction payload rather than executing a state change, and it states the owner-signature requirement. It does not mention cancellation/overwrite behavior or output delivery details, but the core non-execution behavior is 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?

Two short sentences, with the main action front-loaded and only one essential prerequisite statement. There is no filler or repetition of schema contents.

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 4-parameter tool with no annotations and no output schema, the description is largely sufficient: it defines the action, the non-execution nature, and the owner prerequisite. It does not detail the exact shape of the returned unsigned payload or chain/fee context, but that is a minor gap for selecting and invoking 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%; domainName, priceInEth, durationDays, and sellerAddress all have meaningful descriptions including formats and a default. The tool description adds only high-level context (owned domain, owner signature) that mostly restates the schema comment on sellerAddress, so the schema carries the parameter-semantics burden. 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?

States a specific action ('prepare an unsigned transaction payload to list') and a specific resource ('owned .i domain'), plus the marketplace context. This is clearly distinct from sibling tools like marketplace_buy_domain and marketplace_cancel_listing, so an agent can identify it by description alone.

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?

Describes the listing task and a hard prerequisite (owner wallet signature), which gives clear context for when to invoke it. It does not explicitly name alternative tools or situations to avoid, but the action is unambiguous enough that an agent can route to it from a seller's 'list for sale' request.

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 usefully discloses that the tool produces an unsigned payload and that the buyer must sign, which prevents an agent from assuming an on-chain transaction occurs. However, it does not explain what happens after signing, whether the offer is submitted immediately, or whether any listing state is required.

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 sentences with no filler. The core action and object are front-loaded, and the critical signing requirement is placed clearly in the second sentence.

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 is minimally adequate for an agent to understand the tool's purpose and select it, and the schema documents all parameters. However, since there is no output schema, the return payload shape is not described, and the signing/submission flow is only hinted at. For a financial transaction-prep tool, this leaves meaningful ambiguity.

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 every parameter already has a meaningful description, including an ETH example for offerPriceInEth. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score 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 names a specific action — preparing an unsigned transaction payload — and a distinct resource: an ETH offer on a registered .i domain. It clearly distinguishes this from direct purchase (marketplace_buy_domain) and from accepting offers (marketplace_accept_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 implied: use this when making an offer on a .i domain rather than buying it directly. However, it does not explicitly contrast this tool with marketplace_buy_domain, marketplace_accept_offer, or marketplace_cancel_offer, nor does it state prerequisites or 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 provided, the description carries the transparency burden. It states the tool returns unsigned calldata, destination address, and value for wallet signature, making clear it does not broadcast the transaction. It also discloses permanence and the 0.001 ETH cost, which are useful behavioral facts 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 two tight sentences that front-load the purpose and then give the essential output fields. There is no filler, repetition, or unnecessary schema content.

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

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

For a tool with no output schema and no annotations, the description covers the core contract: what it returns, that it is unsigned, and that the registration is permanent. It could additionally mention that the payload must be signed and broadcast separately, but the essential call context 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 input schema has 100% parameter description coverage, so the baseline is 3. The description adds context about the fixed fee and return payload but does not add per-parameter semantics for domainName, recipientAddress, or targetChainId. No extra compensation is needed given the schema covers all 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 names a specific action ('prepare an unsigned on-chain transaction payload') and a concrete resource ('.i sovereign domain'), and it clarifies the output type. It is distinct from siblings like check_domain_availability or transfer_domain, though it does not explicitly name any 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 register_domain versus related tools such as estimate_registration, check_domain_availability, or marketplace_buy_domain. It also does not mention prerequisites like checking availability first; usage is only implied by the tool's obvious purpose.

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

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

No annotations 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?

With no annotations, the description carries the full burden and meaningfully discloses that this only prepares an unsigned transaction payload and requires a user wallet signature. This prevents the agent from assuming the tool broadcasts the transaction. It does not detail overwrite behavior or response shape, but the unsigned/signature distinction is high-value 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?

A single sentence packs the key facts: what is prepared, the action (set/update), the resource, the network, and the required signature. No filler or redundant restatement of the tool name.

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 no output schema, the description covers the main action and an important prerequisite (signature). However, it does not say what the returned payload looks like, whether an existing primary domain is replaced, or whether there are constraints on the domain/wallet relationship. These gaps are notable but not fatal.

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 describes both parameters at 100% coverage: domainName is a .i domain and ownerAddress is a 0x EVM address. The description adds no further parameter-level meaning beyond the schema, 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-resource combination: 'Prepare an unsigned transaction payload to set or update the primary reverse resolution domain identity.' It also names the network (Arbitrum One) and the target ('given wallet address'), making the tool's function concrete and distinguishable from siblings like resolve_domain_identity or register_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 description provides clear context for when to use the tool: when the user wants to set or update the primary reverse resolution domain for a wallet on Arbitrum One. It does not explicitly name alternatives or when-not conditions, 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?

In the absence of annotations, the description discloses the key behavioral fact that the tool prepares an unsigned payload rather than executing a transfer, and that a signature is required. However, it does not clarify the output format, whether ownership is verified, or what happens if the domain is not owned by the provided owner.

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 the core verb-object construction front-loaded: 'Prepare an unsigned ERC-721 transferFrom transaction payload.' The essential requirement ('Requires owner wallet signature') is appended without extraneous 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 no annotations and no output schema, the description covers the main purpose and prerequisite, but lacks important context such as the returned payload structure, whether the tool validates the current owner, and any network-specific considerations. It 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 schema has 100% description coverage, with clear self-describing parameters (domainName, currentOwner, newOwner). The description adds no parameter-specific detail beyond the schema, but the baseline is 3 because the schema already sufficiently documents the 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 states a specific action ('prepare an unsigned ERC-721 transferFrom transaction payload') with a clear resource ('.i domain') and target recipient ('another 0x EVM wallet address'). This clearly distinguishes transfer_domain from sibling tools like bridge_domain, register_domain, and marketplace actions.

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

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

No guidance is given on when to use this tool versus alternatives such as bridge_domain or marketplace_buy_domain. The description mentions a prerequisite ('requires owner wallet signature') but does not explain the selection context or when not to use this tool.

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

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

With no annotations, the description carries the burden and succeeds in disclosing the key behavioral trait: it only prepares an unsigned transaction payload, not a broadcast. It also notes the owner-signature requirement, covering auth needs. Missing details like return format are minor given the clear 'payload' framing.

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 delivers the core function and requirement with zero fluff. Every phrase earns its place, and the key differentiator (unsigned payload) appears immediately.

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 6 parameters, nested objects, no annotations, and no output schema. The description compensates by clarifying the transaction-preparation nature and the owner requirement, but does not describe the exact return payload structure, leaving some ambiguity for an agent needing to sign and submit 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%, so the baseline is 3. The description adds grouping by listing social links, website URL, and IPFS avatar CID, which maps to schema parameters, but does not add meaning beyond what the schema already provides for 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 states a specific verb ('prepare') and resource ('unsigned transaction payload to update... profile metadata') with concrete fields. It clearly differentiates from siblings like register_domain or transfer_domain by focusing on profile updates built as an unsigned payload.

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 a prerequisite ('Requires owner wallet signature') and implies the use case, but does not name alternatives or state when not to use it. Sibling differentiation is left to the agent to infer from the tool name and purpose.

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