marketplace

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

With no annotations, the description carries the burden and discloses a meaningful behavioral trait: it returns a FRESH live-content snapshot and lists included fields (principal, claimable rewards, voting/earning power, as_of_block). It does not mention potential errors or limitations, but the freshness/as-of-block detail is valuable.

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 with the core purpose front-loaded and the unique 'live snapshot' detail appended. 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?

The description is adequate for a simple one-parameter lookup and names key return fields, but with no annotations and no output schema, more detail about orderHash and sibling-tool boundaries would be needed for full completeness.

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 0% description coverage, and the description never mentions orderHash or how to obtain it. 'One order' implies orderHash identifies the target, but the description does not compensate for the missing schema documentation.

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

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

The description clearly states the tool returns full detail for a single order, including a live-contents snapshot with specific fields. It is distinguishable from plural list siblings like get_listings and get_orders, though it does not explicitly name them.

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

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

Usage is implied: call this when you need detailed, current information for one order. There is no explicit guidance on when to prefer it over get_orders or get_listings, nor any 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 behavioral disclosure burden. It usefully reveals sorting, the discountPct computation, and the reference formula for underlying pricing. It does not mention pagination, empty-result behavior, authentication, or that this is a read-only operation, which are meaningful gaps for a tool with no annotation safety hints.

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

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

The description is three tight sentences with no filler. It front-loads the purpose, then efficiently describes row semantics and sort order, so every sentence earns its place.

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

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

For a moderate-complexity read tool with no output schema and no annotations, the description gives the essential return semantics and ordering but omits guidance on parameter selection, especially `kind` and `limit`, and does not help distinguish this tool from several similar siblings. It is minimally viable 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 only 60%, and the description does not compensate for the undocumented `kind` and `limit` parameters. It does define `discountPct` conceptually, which slightly illuminates `minDiscountPct`, but it adds little meaning beyond the schema's own parameter descriptions.

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

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

The description clearly states the tool returns active listings/auctions for a market, and specifies the row contents (ask, underlying contents, discountPct) and sort order. This differentiates it reasonably from siblings like get_listing_details or get_orders, though it does not explicitly name them.

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 'for a market' implies the primary use case, and the sorting/filtering details suggest it is a market-level listing browse tool. However, it gives no explicit guidance on when to prefer this over get_listing_details, get_orders, or other sibling listing tools, leaving selection largely 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?

No annotations are provided, but the description explicitly discloses a non-obvious behavior: order status is reconciled asynchronously and should be treated as advisory until fill. It also signals a read-only operation via 'List.' While it omits details like pagination or return shape, the key operational caveat is present.

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, front-loaded with the core purpose and a useful caveat in the second sentence. 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 simple read-only list tool, the description provides the key facts: what is listed, from whose perspective, and a caveat about status reliability. It does not cover pagination or return shape, but no output schema exists and these are less critical given the straightforward 'List orders' 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?

The description clarifies that `offerer` is the address that created the orders, adding role semantics beyond the schema's regex. It does not explicitly describe the `status` parameter or that it acts as a filter, though the enum values in the schema make its meaning inferable. With 0% schema description coverage, the description only partially compensates for the second 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 names a concrete action ('List') and a clear resource ('orders created by an address'), with a parenthetical enumerating the order types ('listings, auctions, offers'). This makes the tool's scope distinct from sibling tools like get_listings or get_recent_trades without needing to open their schemas.

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

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

The description implies the main use case (fetch an address's orders) and warns about status freshness, but it never names alternatives or states when not to use this tool. An agent must infer the boundary vs get_listings or get_owned_positions, so the guidance is only implicit.

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 adds a meaningful caveat about voted/attached positions not being transferable, which is useful, but it does not disclose potential return-shape behavior, pagination, or whether all owned positions are always returned.

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 core action and resource, then attaches the important listability qualifier. There is no filler or redundant wording.

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 read-style tool, the description covers purpose and a key behavioral caveat. But with no annotations and no output schema, it leaves return shape and edge-case behavior unmentioned, so an agent may need to infer those details.

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 0%, so the description must explain the parameters. 'An address owns in a market' clearly maps to the owner and marketId parameters, but it does not explicitly attach those names or add detail about marketId format beyond the schema pattern.

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 ('List') and names the exact resource: positions owned by an address within a market. It also adds a distinguishing detail about listability that separates it from generic listing tools like get_listings or get_recent_trades.

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 intent is clear: use this when you need the positions an address owns in a specific market. However, it does not explicitly mention when not to use it or point to alternatives among the sibling tools, so guidance is implied rather than 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 behavioral disclosure burden. It explains the exact vs. fallback amount semantics, fee inclusion, exact:true/false flags, and the upper-bound caveat for inexact rows. This is substantive behavioral context, though it omits ordering and pagination behavior.

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

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

The purpose is front-loaded and the detailed amount caveat is packed into a single dense sentence with no filler. The structure is efficient, though the nested parenthetical makes it slightly harder to parse.

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

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

Given no output schema or annotations, the description covers the critical amount semantics well but leaves gaps: result ordering, effective default limit, and behavior when no trades exist. It is adequate for a simple fetch tool 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?

Schema description coverage is 0%, and the description does not compensate by explaining marketId or limit. It references 'a market' but gives no ID format, no default/effect of limit, and no guidance beyond what the JSON schema already states through type and constraints.

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 identifies the tool as returning recently settled sales for a market, which distinguishes it from sibling tools like get_listings and get_orders. It lacks an explicit verb but the resource, scope, and domain 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 intended use case is implied: use this when you need recently settled trade/sale amount data for a market. However, it does not explicitly state when to prefer this tool over get_listings, get_orders, or other alternatives, nor does it mention 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 of behavioral disclosure. It conveys that this is a listing operation and indicates the returned fields, but it does not mention possible side effects, pagination, ordering, or any access considerations. For a simple no-parameter list tool, this is adequate but not rich.

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 wasted words. The main action is front-loaded, and the parenthetical field list adds useful detail compactly.

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 listing tool, the description gives enough context to understand the resource and return fields. It lacks explicit usage routing or edge-case behavior, but the simplicity of the operation means nothing critical 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?

The tool has zero parameters, so parameter semantics are not a concern. The description does not need to add parameter-level detail, and the baseline of 4 applies.

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

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

The description clearly states a specific action and resource: list the markets that the marketplace facilitates, and specifies the included fields (asset, chain, currencies, fee). It is easy to distinguish from siblings like get_listings or get_orders, though it does not 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 purpose implies use when an agent needs to know available market configurations, but the description gives no explicit guidance on when to choose this tool over alternatives such as get_listings. The usage context is inferable but 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 disclosure burden. It does add one genuinely useful behavior — webhook URLs are redacted to origin, which affects what an agent can do with the results. However, it leaves read-only safety, pagination, and empty-wallet behavior unstated.

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, tight sentence with the verb and resource front-loaded and the redaction caveat cleanly parenthesized. Every word earns its place, and nothing is duplicated from the schema.

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

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

Since no output schema exists, the description should at least hint at return shape; the redaction note partially does this by describing what is NOT returned. But subscription fields, pagination, and empty-result behavior are all unspecified. This is adequate for a single-parameter read tool but has clear gaps.

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 0%, so the description must compensate. It does clarify that the wallet parameter is the subject whose subscriptions are listed, adding semantic meaning to the bare schema field. But it adds nothing beyond that role, such as address format expectations or edge-case behavior.

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 ('List') with a specific resource ('a wallet's notification subscriptions'), and the parenthetical about webhook URL redaction sharpens the scope further. The read-oriented verb clearly distinguishes it from the sibling mutation tools subscribe_notifications and unsubscribe_notifications.

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 call this vs. alternatives, and there are no exclusions, prerequisites, or contextual cues. The read/write separation from the subscribe/unsubscribe siblings is only implied by naming conventions, never 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 behavioral burden. It discloses that the tool returns calldata rather than executing the cancellation, that Seaport enforces msg.sender == offerer, and that a subsequent confirm step is required. This gives an agent a solid understanding of the safety and workflow, though it does not detail failure modes or invalid-order handling.

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

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

Three concise sentences with no filler. Each sentence contributes: what the tool does, an authorization/safety note, and the post-confirmation workflow. It is well-structured and front-loaded.

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

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

For a single-parameter tool with no output schema and no annotations, the description covers the core invocation context: purpose, authorization restriction, return nature, and next step. It could be more complete by describing the expected orderHash format, but overall it gives an agent enough to act 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 schema has 0% description coverage and the description does not explain the orderHash parameter's format or meaning beyond the tool's purpose. While 'orderHash' is reasonably self-explanatory, the description adds no explicit value to the schema, so an agent must infer details from the parameter name alone.

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

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

The description clearly identifies the action: preparing an on-chain Seaport cancel transaction for an active order. It distinguishes itself from sibling tools like prepare_listing and prepare_purchase by the cancel verb and Seaport context.

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 makes the intended use obvious: cancel an active Seaport order. It also includes a critical constraint—only the offerer can execute—and provides the follow-up step of posting the txHash after confirmation. It does not explicitly name sibling alternatives or exclusion conditions, but the context is clear enough.

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

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

With no annotations, the description carries the full burden and excels: it discloses preconditions (ownership, transferability not voted/attached), server-side fee injection, the exact deliverable (one-time NFT approval + EIP-712 typed data), and the non-custodial property (never signs or holds keys). This gives an agent a clear security and side-effect model.

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

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

The description is three sentences with no wasted words, front-loading the primary purpose and then adding essential behavioral details. Every clause earns its place, and the final 'Never signs or holds keys' is a compact high-value security note.

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 10-parameter tool with no output schema or annotations, the description covers the essential context: purpose, preconditions, process, and deliverable. It doesn't explain the exact return structure beyond the typed-data summary or error cases, and doesn't describe how the returned approval/signature should be used downstream, but it provides enough for an agent to decide and invoke Correctly.

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

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

The description adds no direct parameter explanations and relies on the schema, which covers 60% of parameters. The 'SELL listing or Dutch auction' phrase indirectly maps to the kind enum, and the ownership check touches the seller parameter, but marketId, durationDays, and the relationship between startAsk/endAsk remain under-explained. This is adequate given the moderate 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?

States a specific action (prepare), resource (SELL listing or Dutch auction), and key distinguishing behaviors (ownership verification, Seaport order, returns approval + typed data). The explicit 'SELL' clearly differentiates it from sibling prepare_offer and prepare_purchase, and the Dutch auction mention distinguishes it from prepare_cancel.

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 when to use the tool: when a seller wants to list an NFT or start a Dutch auction. It doesn't explicitly name alternatives or exclusions, but 'SELL' and 'seller OWNS the position' route the agent away from buy-side or cancellation tools. Lacks an explicit 'use prepare_offer instead for bids', but the context is strong enough.

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

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

With no annotations, the description carries the behavioral disclosure burden and does so well. It reveals the tool returns an EIP-712 order to sign, flags that currency approval is needed, and clarifies that settlement stays on Seaport rather than being executed by this tool.

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

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

Two dense sentences front-load the purpose and then explain the signing/POST workflow and Seaport settlement. Every clause earns its place with no redundant or filler content.

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

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

For a tool with seven parameters and no output schema, the description provides enough procedural context: what is returned, the approval requirement, and the next action. It does not enumerate exact response fields, but the schema covers most input semantics and the description covers the follow-up workflow.

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 description adds workflow-level context but no per-parameter detail. Schema coverage is 71%, and the required marketId field is not documented in either the schema or the description; however, the remaining parameters are meaningfully described in the schema itself.

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 the specific action 'Prepare a BID/offer on a position' and lists the concrete deliverables (Seaport order to sign, currency approval, submission steps). This clearly distinguishes it from siblings like prepare_listing and prepare_cancel.

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 'BID/offer' framing and the workflow (read Seaport counter, sign, POST) give a clear use context: when an offer needs to be prepared for signing. It does not explicitly name alternatives or when-not-to-use conditions, but the offer-side intent is unambiguous.

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 present, the description bears full burden and delivers richly: it discloses the custody model ('The agent's own wallet signs and submits — this never signs or holds keys'), Dutch-auction interpolation with asOf timing, the approval grant logic (approveBaseUnits slightly above quote, never above maxTotalBaseUnits), and the optional auction cleanup transaction that zeroes residual allowance.

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

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

Four dense sentences, each carrying distinct information: purpose and output composition, pricing/approval behavior, auction cleanup, and custody safety. Purpose is front-loaded in sentence one, with no filler and no restating of schema facts.

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 — no annotations, no output schema, one undocumented parameter — the description covers the return package (summary with asOf quote, approvals, calldata, snapshot, optional cleanup) and key edge-case behavior. Remaining gaps are minor: orderHash provenance/validation and error conditions, plus reliance on Seaport domain jargon.

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

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

The single required parameter (orderHash) has 0% schema coverage, and the description never explicitly defines it or states where to obtain it (e.g., from get_listings or get_listing_details). It compensates only implicitly by repeatedly referring to 'the order' (decaying order, maxTotalBaseUnits), so an agent must infer that orderHash identifies the listing/offer being purchased.

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

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

States a specific verb and resource — 'Prepare the non-custodial transaction package to BUY a listing (or accept an offer)' — and enumerates the package's components: ordered approvals, Seaport fulfillOrder calldata, and a fresh contents snapshot. The buy/fill semantics ('fulfillOrder calldata') distinguish it from sibling prepare_offer, which creates offers rather than filling them.

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

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

Provides clear usage context: use when buying a listing or accepting an offer, which contrasts with the get_*/list_* read siblings and the other prepare_* write tools. However, it never explicitly names an alternative or states when-not-to-use, leaving exclusive routing 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, the description carries the full burden and meets it: it discloses the mutation side-effect (subscribe), the two-step signing protocol, chain-specific signature validation, the single-use nature of signatures with the 409 replayed_signature behavior, and that the webhook HMAC secret appears only once in the response. This is unusually transparent about failure modes and constraints.

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?

Every sentence adds a distinct operational fact: what it is, how to call it, which chainId to pass, what to do on replay, and how to verify the webhook. The flow is logically ordered from summary to two-step protocol to pitfalls to response handling, and there is 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 complex 8-parameter tool with no output schema, the description covers the critical process, failure modes, and verification. It does not describe the inapp channel alternative (the description is webhook-centric), nor the savedSearch parameter's full semantics, though the schema documents those details. Given the schema coverage, this is a minor gap.

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 description adds meaning far beyond the schema: it explains the signature parameter's presence/absence controls the two-step flow, that chainId is part of the signed message and must match the wallet's actual signing chain, that timestamp needs freshness, and that events map to the listed notification types. This compensates for the schema's 50% 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 uses a specific verb ('Subscribe') with a direct object ('a wallet') and an explicit resource ('push notifications') and names the three event types. It distinguishes itself from polling and, via wording, from sibling tools like unsubscribe_notifications and list_subscriptions, so an agent knows exactly what operation this is.

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

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

It explicitly frames the tool as 'the agent-native alternative to polling,' giving a clear when-to-use signal, and walks through the required two-step flow (call without signature, then with signature). It does not explicitly contrast with sibling subscription-management tools, but the workflow guidance is strong.

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. It discloses several non-obvious behaviors: the two-step signing flow, that `chainId` is signed over and verified on that chain, and that signed messages are single-use. It could add more about response behavior or failure modes, but it covers the most important traits.

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

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

The description is three sentences long and front-loaded with the core purpose. Every sentence earns its place: the deletion action, the two-step procedure, the chain verification, and the single-use constraint. There is no redundant or filler content.

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

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

The tool is moderately complex due to the two-step signing flow, but the description explains the overall workflow well. However, there is no output schema and no annotation fallback, and the description does not explain what the first step returns beyond "the message to sign," nor does it clarify the semantics of required parameters like `timestamp` and `subscriptionId`. It is adequate but leaves clear gaps.

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 only 20%, with just `chainId` described. The description adds useful context for `chainId` and the optional `signature`, but it does not explain `wallet`, `timestamp`, `subscriptionId`, or how the signature produced in step one is used in step two. Parameter names and patterns provide some hints, but this is insufficient for a signed two-step flow.

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: "Delete a notification subscription." This clearly identifies the tool's purpose and distinguishes it from the sibling subscribe_notifications by referencing the same two-step flow while noting the deletion action. There is 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 gives clear invocation context: it is a two-step operation and the agent should call without `signature` first to obtain the message to sign. It does not explicitly name alternatives or when-not-to-use conditions, but the deletion purpose and reference to subscribe_notifications provide clear enough guidance.

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