Bernuvia

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

With no annotations, the description carries the full burden. It states only the primary action but does not disclose side effects such as duplicate handling, overwriting behavior, or error conditions. It also does not mention whether the operation is idempotent or requires any preconditions. This is a significant gap for a mutation tool.

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

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

A single sentence with no fluff. It is appropriately concise for a simple operation, though it could be slightly more informative without becoming verbose. The structure is front-loaded with the action.

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

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

Given the simple nature (one parameter, no nested objects), the description is minimally sufficient but lacks critical context such as success/failure behavior, potential errors, or what the output schema contains. The presence of an output schema mitigates the need to explain return values, but behavioral nuances are still missing. A more complete description would mention duplicate handling or confirmation.

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% (slug is described as 'Slug of the template to add.'). The description adds no extra meaning beyond the schema, just reiterates 'template'. Baseline 3 is appropriate since the schema already documents the 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?

States a clear verb and resource: 'Adds a template to the cart.' It distinguishes from remove_from_cart by implying addition vs removal. However, it does not specify whose cart or the scope, but the slug parameter implies a specific template. It is clear and specific enough.

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 on when to use this tool versus alternatives like remove_from_cart or my_cart. It does not mention prerequisites (e.g., must be logged in) or exclusions. The context implies it is for adding items, but the description does not explicitly differentiate it from other cart-related tools.

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

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

No annotations are provided, so the description must carry behavioral disclosure. 'Returns' implies a safe read, and it discloses the aggregate shape of the response, but it says nothing about pagination, permissions, or how date-range boundaries behave. Since an output schema exists, the return-shape detail is partly redundant.

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 that packs the resource and all returned dimensions with no filler. It is dense but readable; no sentence is wasted.

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 read-only, no-required-parameter stats tool with a fully documented schema and an output schema, the description covers what the tool does and what it returns. The only real gap is the lack of routing guidance versus sibling sales/balance tools.

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 ('from'/'to') already document format and defaults. The description only restates 'by date range' without adding syntax, inclusivity, or default behavior beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb+resource ('Returns the builder's sales stats') and enumerates the metric dimensions (count, gross, net, released, by day, by template) plus lifetime totals, which is unusually concrete. It does not, however, distinguish itself from the sibling 'my_sales' or 'my_balance', so an agent must infer the boundary.

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?

There is no when-to-use statement, no indication of when to prefer this over 'my_sales' or 'my_balance', and no prerequisites or auth context. Usage is only implied by the name and metric list.

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 delivers: the live-signature exposure, that `authorizer` is server-set so a signature can only burn your own authorizations, the three return modes (typedData without signature, calldata with signature, server-broadcast with broadcast:true), sponsored-gas limits, and the post-confirmation `orderClosed` outcome including the already-used/already-cancelled cases.

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?

It is front-loaded with the purpose and keeps every clause informative, but it is one dense paragraph with parenthetical asides that make scanning harder than a short structured list would be. Little is wasted, though readability suffers slightly.

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-required-parameter, nested-object tool with an output schema, the description covers the full invocation lifecycle and even flags the `orderClosed` field so the agent knows what to read from the response. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond the schema: it explains the derivation of nonce from quote, why `nonce` survives a newer quote, and that `authorizer` is never client-supplied. That goes past restating field definitions.

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

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

The opening clause names a specific verb and resource — 'Withdraws a gasless-deposit authorization you already handed over' — and immediately explains the risk it mitigates. Combined with its sibling set (deposit_data, submit_signed_deposit), an agent can tell exactly what this does and how it differs from depositing.

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

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

It gives explicit routing between the two invocation paths (`nonce` vs `{ orderId, quote }`) and states which to prefer ('so as not to leave live signatures behind'). It does not, however, frame when to cancel at all versus letting a quote expire or using another sibling tool, so the when-not-to-use side is only implied.

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, and it delivers: nothing is created or changed, the uploadToken is not spent, the same error codes as a real submission are returned, and it never echoes a found secret value nor the matched catalog template. It also discloses the advisory-only nature (human review decides) and its own hourly cap plus the prefilter quota.

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?

It is front-loaded with the core idea ('DRY RUN ... creating and changing nothing'), which is good, but the body is a single dense paragraph with nested parentheticals and asides that is hard to scan. The information is largely non-redundant given the tool's complexity, but the structure reads as a wall of text rather than cleanly partitioned guidance.

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, three-parameter mutation check with no annotations, the description is complete: it covers scope, side-effect freedom, error-code parity, advisory status, content-filter behavior, quotas, and what it deliberately excludes. An output schema exists, so it correctly does not spend space explaining return values.

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

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

Schema coverage is 100%, so all three parameters (file, template, runContentFilter) are already documented in the schema, and the baseline is 3. The description reinforces meaning (file is the already-uploaded ZIP, template is the listing validated under the same rules) but adds little syntax or constraint detail beyond the structured field 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?

States a precise verb and resource — a dry-run validation that creates and changes nothing — and immediately grounds it in the artifacts it uses ('the ZIP you already uploaded with zip_upload_link'). It explicitly distinguishes itself from the sibling that actually submits ('the same file still works later for submit_for_review'), so an agent can route between them without opening schemas.

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

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

Gives the when ('DRY RUN before publishing'), the when-not (it does NOT judge content policy — that is read with legal_versions), and names the alternative (submit_for_review, Content policy). It also conditions the optional AI prefilter on agent accounts plus a `template` with no blocking issues.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the FULL amount (no fee) is credited to the agent's own wallet inside the escrow, that withdraw() must be called to move funds out, and that the agent has no withdrawal_data and must not withdraw the owner's money. It also notes the rejection outcome when the deadline has not expired, which is genuinely useful failure context.

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

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

The precondition is front-loaded, which is the most important routing signal. The three sentences are dense but each earns its place, though some escrow/contract terminology could be trimmed without losing 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?

An output schema exists, so return values need not be described. Given a single-parameter mutation tool, the description still covers the precondition, the correct deadline source, the fund destination, and the mandatory follow-up withdraw() step, leaving no gap an agent needs before invoking 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% and the single orderId parameter is already documented as the uuid of the expired-dispute order. The description references orderId only incidentally in the calldata signature, adding no format or validation detail beyond the schema, so the baseline 3 applies.

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

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

The description names a concrete action (resolve an expired dispute via resolveDisputeByTimeout(orderId) calldata against the escrow the order was funded in), giving a specific verb+resource+temporal condition. It is clearly separable from siblings like withdraw_dispute, open_dispute, and dispute_status.

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

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

It states a strong precondition: 'Only when YOUR dispute's deadline expired without resolution,' and explains that the operative deadline is effectiveDeadline (readable via dispute_status, possibly extended by the team). It does not explicitly name which sibling to use instead for other dispute outcomes, so it stops short of full when/when-not routing.

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

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

No annotations are provided, so the description carries the behavioral burden and does add value: the single-draft-per-account collision behavior, the image-path requirement tied to image_upload_link, and the note that schema defines allowed values and limits. It doesn't cover what happens on partial failure or permissions, but the collision semantics are a genuinely useful disclosure.

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 tight sentences front-loaded with the core action and collision rule, then the field-sourcing rule. Slightly dense with parenthetical asides (backticks, ALL-CAPS emphasis) but every clause 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 18-param mutation tool with no annotations, the description supplies the collision rule, image-source dependency, and 'schema is authoritative' note. Output schema exists so return values needn't be explained. Missing only edge-case error handling beyond the collision, which 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?

Schema coverage is 100% (baseline 3), and the description adds relational meaning beyond field-level docs: gallery/bannerUrl paths come from image_upload_link, category/platforms are closed lowercase lists, price is a number, licence is standard|exclusive, and that anything not in the schema is not required. This cross-field context exceeds the schema's per-field notes.

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

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

States a specific verb+resource ('Creates the publish draft') and immediately differentiates from siblings by naming the failure mode and the two alternative tools (update_draft, delete_draft). An agent can route correctly without opening any schema.

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

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

Explicit when-to-use ('it fails if one already exists: carry on with update_draft or delete it with delete_draft') and clarifies prerequisites ('There is no article to read first'). Names the exact alternatives for the 'already exists' branch.

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

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

With no annotations, the description carries the full burden and does well: it discloses the financial risk ('gives away margin'), the irreversibility of the name ('taken for good'), the confirm guardrail, and the per-template cap of 10. It does not mention who may call it or whether an existing code can be deactivated later, which is the one notable gap.

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

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

A single dense sentence that front-loads the verb, resource, and scope, then layers constraints and the confirmation requirement. Every clause carries information, though the parenthetical constraint stack is slightly cramped.

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?

An output schema exists so return values need not be explained, and the description covers the mutation's risk profile, required confirmation, and limits. Missing only permission/authorization context, which matters for a platform-wide mutation with no annotations to fall back on.

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

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

Schema description coverage is 100%, so all six parameters are already documented (including the long confirm rationale). The description restates the code length range and discount range but adds one genuinely new fact: the maximum of 10 codes per template, which is not in the schema. Baseline 3 is right when the schema does the heavy lifting.

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

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

States a specific verb and resource (creates a discount code) and immediately scopes it to 'YOUR templates' with named constraints, which separates it from catalog-wide or activation siblings like set_promo_code_active and my_promo_codes. An agent knows exactly what this produces and its limits without opening the schema.

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

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

Usage is implied through constraints ('they have to be named', 'at most 10 codes per template from here', 'requires confirm=true') rather than stated as when-to-use versus alternatives. It never routes the agent to set_promo_code_active for deactivating an existing code or explains when creating a new code is preferable. Adequate but with a clear routing gap.

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

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

With no annotations, the description carries the full burden and does so: it discloses that the operation is irreversible, requires confirm=true, affects the single account-level draft, and has elevated risk for EDIT drafts. This is exactly the destructive-operation context an agent needs before calling.

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 critical fact and the confirm gate are front-loaded, which is good, but the phrasing is run-on and the closing sentence ('It is what lets you start another one with create_draft without going through the website') is vague and adds little operational 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?

An output schema exists, so return values need not be described. The description covers the destructive nature, the confirmation requirement, the pre-check workflow, and the sibling hand-offs, leaving nothing an agent needs in order to call this safely.

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

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

Schema coverage is 100% and the single parameter's description already explains that confirm must be true and that the draft is unrecoverable. The description reinforces rather than extends this, so it earns the baseline 3 rather than more.

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 (DELETES) and resource (the saved publish draft), plus the cardinality constraint 'there is ONE per account'. This clearly distinguishes it from sibling write tools like create_draft, update_draft, and the read-only my_draft.

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

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

Explicitly names the alternatives and when to use them: check contents via my_draft and ask the person before deleting, with extra caution for EDIT drafts that represent pending changes to a published template. It also notes the follow-on path (create_draft) rather than website deletion.

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 it delivers: it discloses that msg.sender must be the linked wallet (not the owner's), that Bernuvia neither signs nor pays gas, that the purchase belongs to the owner, and that completing the deposit accepts terms and waives the 14-day withdrawal right. It omits failure/idempotency behavior, but the safety-relevant traits are unusually well covered.

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

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

Purpose and return behavior are front-loaded, and most sentences carry distinct information. It is information-dense to the point of being heavy, the caps emphasis (YOU/YOUR) is noisy, and the final sentence overlaps the acceptTermsAndImmediateDownload parameter description.

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

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

For a multi-step web3 flow the description covers the prerequisite, the signing/gas split, the wallet constraint, and the terms/withdrawal consequence, and an output schema exists so return values need not be restated. Minor gaps remain around error conditions and the quote-expiry mechanics it only alludes to.

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 orderId, singleSignature, and acceptTermsAndImmediateDownload, including the EIP-3009 flow and non-contract-wallet constraint. The description largely restates the terms-acceptance semantics rather than adding new parameter meaning, so baseline 3 applies.

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

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

The description states a specific verb and outcome: it returns the Bernuvia-signed quote plus the USDC approve/fundPurchase calldata the agent signs. It anchors itself to the sibling prepare_payment as the prerequisite and implicitly the non-gasless counterpart to submit_signed_deposit, so the agent can distinguish it without opening the schema.

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

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

The prerequisite chain is explicit (for an order created with prepare_payment), and the schema documents the optional gasless alternative that routes to submit_signed_deposit. However, the main description gives no explicit when-not or sibling comparison; the routing lives mostly in the parameter description rather than the headline guidance.

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

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

No annotations, so the description carries the full burden; it discloses that this is read-only ("The seller only reads status and deadlines: no thread, no evidence, no actions") and enumerates the returned state (window, effectiveDeadline, extensions, reopenings, timeout, decision/execution). It omits permission/auth requirements and whether an extended deadline has side effects, so it stops short of a 5.

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

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

Front-loads the core purpose and the exclusion list before the return-value inventory. It is somewhat run-on with all-caps emphasis and a long clause chain, but every sentence carries routing or behavioral information rather than filler.

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

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

With an output schema present, the description need not explain return values, yet it still covers scope, exclusions, and the read-only constraint. For a single-param read tool this is thorough; minor gap is the absence of any permission/access note.

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 the single orderId's accepted formats (uuid or purchaseId from my_purchases/my_sales) are already documented in the schema. The description only restates "asked for by order id," adding no meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (read status and deadlines) and resource (one order's dispute) scoped to a single order id, and explicitly names the siblings it is not (my_cases, my_evidence). An agent can distinguish it from order_status, my_cases and my_evidence without opening any schema.

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

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

Gives an explicit use condition ("pick it when you already know which order you mean and you need the clock and the next step") and excludes alternatives by name ("Not for finding out WHICH cases... that is my_cases", "not for the evidence file... my_evidence"). Routing 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, the description carries the full burden and discloses key traits: the link is temporary (10 minutes), requires a paid purchase, and returns a SHA-256 checksum for verification. It omits authentication requirements, single-use semantics, and error behavior, so it is not fully 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?

A single sentence that front-loads the action, includes the expiry constraint, the precondition, and the verification artifact. Every clause earns its place with no redundancy.

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

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

An output schema exists, so return values are covered elsewhere. The description supplies purpose, precondition, TTL, and checksum; only minor details like auth or ownership requirements are absent, which is acceptable for a one-parameter read 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 coverage is 100% and the single parameter purchaseId is fully documented in the schema with a crucial distinction from prepare_payment's orderId. The description adds no parameter-level detail, 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 states a specific verb ('Issues') and resource ('temporary download link') with scope ('for a purchase already paid') and expiry ('10 min'). It is clearly distinct from sibling upload-link tools like evidence_upload_link or zip_upload_link, which perform the opposite operation.

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

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

The phrase 'for a purchase already paid' gives clear context: use only after payment is complete. It does not name alternative tools or state when not to use the tool, but the precondition is explicit enough to guide selection.

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

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

With no annotations, the description carries the full burden and does so: 1h expiry, buyer-only authorization requirement, accepted MIME types, 10 MB size cap, and count range 1-5. It also discloses the returned storageRef and how it relates to submit_evidence.

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?

Information-dense and front-loaded with the core action, but the sentences are long and somewhat run-on, packing expiry, return value, auth, and constraints into one flowing block.

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

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

Complete for an upload-link tool: it covers authorization, file constraints, expiry, count behavior, and the return value's role, even though an output schema exists. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100% and the schema already documents type, count, and orderId in detail. The description restates most of this (buyer-only, same type for all, count) without adding substantial new syntax or format meaning beyond the schema. Baseline 3 for high coverage.

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

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

States a specific verb and resource (issues presigned URLs to PUT evidence files for an order dispute), and disambiguates from siblings like image_upload_link and zip_upload_link by tying it to dispute evidence. It also names the downstream consumer (submit_evidence) via the returned storageRef.

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?

Clear context: it's for adding evidence to a dispute of an order you bought, and count is for issuing several of one type. It states the buyer-only restriction. It doesn't explicitly say 'use image_upload_link for non-evidence images', but the evidence framing makes the routing 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?

No annotations exist, so the description carries the full burden and does so richly: 1 h URL lifetime, PUT-over-HTTP semantics, that the server neither converts nor crops, the exact rejection codes ([IMAGE_ASPECT_RATIO], [ANIMATED_IMAGE_TOO_HEAVY], [ANIMATED_IMAGE_TOO_LARGE], [TOO_MANY_ANIMATED_IMAGES], [INVALID_ANIMATED_IMAGE]), tolerance rules, and the animated-WebP first-frame-to-poster (<path>.poster.webp) storage 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 in the first sentence, but the body is a dense ~250-word run-on with heavy capitalization and stacked parentheticals. Most content is genuinely useful, yet it could be structured into scannable segments instead of one block.

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

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

An output schema exists, so return values need not be explained, yet the description still covers what the answer carries (aspectRatio, animated limits) plus all rejection paths, aspect-ratio enforcement, and animated handling. Nothing an agent needs to call and interpret this tool is missing.

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

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

Schema coverage is 100% and the single `count` parameter is fully documented in the schema (1-21, default 1). The description only restates this ('Ask for several at once with `count`') without adding format or edge-case meaning, so it sits at the baseline for high-coverage schemas.

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

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

Opens with a specific verb+resource: 'Issues presigned URLs (1 h) to PUT WebP images over HTTP, and returns each one's path.' It explicitly distinguishes itself from the nearest sibling by stating the template VIDEO 'does not go through here: it is uploaded with video_upload_link', so an agent can route correctly without opening schemas.

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

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

Gives concrete usage context: the returned paths go into `gallery` (first = cover), `bannerUrl`, and inline <img> in the description, plus when to raise `count`. It names one alternative (video_upload_link) and the condition that selects it, but never contrasts with zip_upload_link or evidence_upload_link, the other upload-link siblings.

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

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

With no annotations, the description carries the full burden and does so extensively: irreversible (only escape is a new agent account), gas-free, signature-based, and it enumerates downstream behavior (stays the paying wallet, receives refunds, collects template sales, never withdraws owner funds). This is exactly the behavioral disclosure annotations would otherwise need to provide.

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

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

Front-loads the core action and the critical one-time constraint in the first two sentences, and the remaining sentences address ownership/refund semantics. Slightly dense with repeated emphasis on the owner/agent distinction, but every sentence carries decision-relevant information.

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

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

For an irreversible, ownership-sensitive mutation with an output schema already covering returns, the description supplies everything an agent needs: the irreversibility, the role semantics, the no-gas requirement, and the boundary against owner funds. Nothing material is missing.

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

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

Schema description coverage is 100% and all three params (nonce, wallet, signature) are documented in the schema, so baseline 3 applies. The description reinforces the signature/nonce flow but adds no format or validation detail beyond the schema.

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

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

States a specific verb+resource ('Links YOUR OWN wallet') and immediately scopes it away from the owner's in-app wallet, which is the key disambiguation against siblings like set_payout_wallet and my_profile. The proof-of-control mechanism (sign a challenge, no gas) is included up front.

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?

Makes the one-shot nature explicit ('IT CAN ONLY BE DONE ONCE') and clarifies the agent-vs-owner ownership boundary, which is the ambiguity an agent would otherwise trip on. It stops short of naming routing alternatives (e.g. 'to change payout destination later, use set_payout_wallet'), so it is clear context without full when-not guidance.

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

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

No annotations exist, so the description carries the full burden and largely meets it: it discloses read-only behavior ('read-only, you can neither withdraw nor spend it') and clarifies which wallet/field governs purchases (agentWallet limiting purchases). It stops short of permission requirements, error behavior, or freshness of the figures, leaving some behavioral gaps.

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

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

The purpose and the exclusions are front-loaded and each sentence carries information. It is somewhat long and repeats the payerWallet-is-a-string point twice, which borders on defensive redundancy for a zero-parameter tool.

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

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

An output schema exists, yet the description still glosses the key returned fields and their meaning (balance scope, purchase limit, canSell), so the agent has everything needed to interpret the call. Combined with the sibling routing, nothing essential is missing.

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

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

The input schema has zero parameters, so there is no input semantics to document and the baseline is 4. The description instead characterizes return fields (ownerWallet, payerWallet, agentWallet, canSell), which adds meaning beyond the empty input schema.

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

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

It states a specific verb and resource ('returns the balance of YOUR OWNER's account') and explicitly bounds scope by naming what it is not for. It names siblings my_capabilities and my_profile and contrasts its purpose against them, so an agent can select it without ambiguity.

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

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

Explicit negative routing ('Do NOT use it for your scopes... that is my_capabilities', 'Do NOT use it for your owner's profile data... that is my_profile') plus positive framing ('the only one of the three account tools that returns FIGURES'). The when/when-not conditions are fully 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, the description carries the full disclosure burden. It adds useful behavioral context: accountType is 'delegate', ownerWallet cannot be used, agentWallet is the one to pay with, and isSeller is time-sensitive ('whether TODAY you may use the seller scope'). It does not explicitly state the tool is read-only, but the identity/permissions framing strongly implies an introspection call.

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 packs a lot of useful field semantics into a dense block. It front-loads purpose and exclusions before diving into field details, and every sentence contributes. The heavy ALLCAPS and run-on field list make it slightly less scannable, but there is no real waste.

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

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

For a zero-parameter introspection tool with an output schema, the description is complete: it explains each field's meaning, constrains which wallet can be used, clarifies the seller scope condition, and identifies when to use sibling tools instead. Nothing critical is missing for an agent to call it appropriately.

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 meaningfully explains the fields that will appear in the output (accountType, ownerHandle, isSeller, scopes, ownerWallet, agentWallet), which adds value beyond the output schema. No parameter-specific documentation is needed.

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 explicitly frames the tool as exposing the credential's identity and permissions ('WHO YOU ARE AND WHAT YOU CAN DO') and gives it a clear role as the tool of permissions. It also distinguishes itself from siblings by naming my_profile for owner profile data and my_balance for balances, so an agent can select it over similar my_* tools.

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

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

The description gives explicit when-not-to-use instructions with named alternatives: do not use it for owner profile data (that is my_profile) and do not use it for balances (that is my_balance, noted as the only one carrying figures). This directly routes an agent to the correct tool without requiring 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, so the description carries the behavioral burden. It conveys read-only intent through 'Returns' and account scoping, which is useful, but it does not disclose auth requirements, error behavior, or whether a nonexistent cart is auto-created. There is no contradiction with annotations.

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

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

A single, front-loaded sentence with no filler: 'Returns the account's cart.' Every word contributes to the operation and resource scope, making it maximally concise.

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

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

With zero parameters and an output schema present, the description does not need to explain return shape. However, it still lacks usage guidance and behavioral caveats such as auth or side-effect behavior, making it 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 has zero properties and schema description coverage is 100%, so there are no parameter semantics to document. The baseline score of 4 applies because no parameter explanation is needed.

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 'Returns' with a clear resource, 'the account's cart,' so the core operation is unmistakable. It does not explicitly differentiate from siblings like my_purchases or my_draft, but 'cart' is a distinct resource and the read intent is clear.

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

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

The retrieval intent is implied by the verb 'Returns,' but the description does not explicitly say when to use this tool versus cart-mutating siblings like add_to_cart or remove_from_cart. There is no when-not-to-use guidance or alternative routing.

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

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

With no annotations, the description carries the transparency burden. It discloses that this is a list/read operation of the user's own cases, includes message threads, and explicitly excludes internal team notes. It does not discuss pagination or ordering, but for a parameterless list this is adequately 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?

Every clause earns its place: the resource/content, a use-condition, and two explicit sibling exclusions. It is front-loaded with the core meaning and contains no filler.

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

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

For a zero-parameter list tool with an output schema, this description is complete: it states the data returned, scopes it to the user's own cases, and routes to the relevant siblings. No additional invoke-time information is needed.

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

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

The input schema has zero parameters, so there is no parameter-specific meaning to document. The description still makes the tool's scope clear, fulfilling the baseline for parameterless tools.

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

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

Description names a concrete resource ('your support cases and disputes') and specifies the content delivered ('state and message thread'). The 'THE LIST' phrasing plus exclusions clearly differentiate it from siblings, 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?

Gives explicit trigger conditions ('when you do not yet know which case you mean, or when you want to read the conversation') and names the alternatives it is not for: dispute_status for a known order id and my_evidence for evidence files. This leaves no ambiguity about when to select 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?

With no annotations, the description carries the full burden and does so well: it discloses the one-draft-per-account constraint, that `missing` is the SAME validation the submission runs, the readyToSubmit semantics, and the video state machine (queued, processing, ready, failed with reason). These are substantive behavioral traits an agent needs to act correctly.

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

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

Front-loaded with the core purpose in the opening clause, followed by actionable detail. It is dense with nested parentheticals but each clause earns its place; only mild run-on density keeps it from a 5.

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?

An output schema exists, so the description need not explain return values, yet it adds interpretive context (validation provenance, video states, vocabulary alignment). Behavior, constraints, and next-step workflow are all covered, leaving little an agent would need beyond the schema.

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

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

Zero parameters, so the baseline is 4. The description instead documents the return vocabulary (prices as numbers, licence standard/exclusive, video state), which is output semantics rather than parameter semantics, but it usefully aligns the response with what create_draft/update_draft accept.

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 (Returns) and resource (the saved publish draft), plus scope: there is exactly ONE per account, shared with the /vender assistant. This clearly distinguishes it from the create_draft, update_draft, and delete_draft siblings by making its read-only retrieval nature explicit.

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?

Implies usage through the submit workflow: with readyToSubmit: true, 'all that is left is uploading the ZIP and calling submit_for_review.' This routes the agent to the next step, though it never explicitly states when NOT to use it or names an alternative retrieval path.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavioral constraints: ownership scoping ('Never anyone else's, and buyer only') and that each item includes its date. It does not cover ordering, pagination or size limits, but the output schema exists so return shape is covered elsewhere.

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

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

Front-loads the resource and what it returns, then routes to alternatives in one dense sentence. Slightly awkward phrasing ('pick it to check what the file already contains') but no filler sentences.

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

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

For a single-parameter read tool with a 100%-covered schema and an output schema, the description supplies everything missing: the scope of returned data, the ownership restriction, and the sibling routing. Nothing an agent needs to call it correctly is absent.

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 there is a single required parameter, so the schema already defines orderId. The description only loosely implies the id is for an order the caller bought, adding no syntax or format detail beyond the schema; 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?

States a specific verb+resource ('THE EVIDENCE YOU filed on the dispute of an order') and explicitly distinguishes itself from siblings by naming dispute_status and my_cases as the wrong tools for adjacent needs. An agent can select it without opening any schema.

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

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

Gives explicit when-to-use ('pick it to check what the file already contains') and two when-not conditions with the correct alternatives named ('Not for that dispute's status... that is dispute_status, and not for the case message thread... that is my_cases').

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 implies a read-only listing with no side effects, which is the main thing an agent needs, but it gives no indication of ordering, whether favorited templates span the user's own and others' templates, or any auth requirements.

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

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

A single front-loaded sentence with no padding or redundancy. Nothing in it is wasted, though it is close to the minimum viable length.

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

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

The output schema covers the return shape and there are no parameters, so little is strictly required. Still, for a zero-arg list tool surrounded by near-duplicate siblings, the description should clarify the favorites scope to remove ambiguity about what this returns.

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

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

The tool takes zero parameters, so there is no argument semantics to explain; per the rubric this is a baseline 4. The description correctly implies the listing is implicitly scoped to the calling user.

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 ('Lists') and resource ('templates saved as favorites'), which is clear. However, it does not distinguish itself from close siblings like my_templates or toggle_favorite, leaving the agent to infer that favorites are a distinct, separately-curated list.

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 when-to-use context is offered. With siblings such as my_templates, search_templates, template_details and toggle_favorite in the same catalog, the description should say when to reach for favorites versus a general template listing; it says nothing.

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

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

No annotations are provided, so the description carries the full burden. It explicitly discloses a non-obvious behavioral trait: 'reading them here does NOT mark them as read.' This is high-value transparency for a notification-reading tool, and no annotations were present to supply it.

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

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

The description is a single, front-loaded sentence that covers action, scope, and the critical side-effect caveat without any 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 no-parameter read-only tool with an output schema, the description states exactly what the agent will receive (latest 20 notifications and unread count) and the important non-marking behavior. There are no ambiguous inputs or missing prerequisites an agent would need to know.

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 input schema is empty, so there is no parameter semantics to document. Baseline 4 is appropriate as the description fully covers the tool's fixed 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?

Description names the specific action ('Reads'), the exact resource ('your latest 20 bell notifications'), and the key outcome ('how many are still unread'). It also adds the crucial distinction that reading here does not mark notifications as read, which prevents it from being confused with a potential mark-as-read tool.

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

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

The description clearly implies the use case: check the latest 20 bell notifications and see the unread count. It does not name sibling alternatives, but no sibling appears to compete for this behavior, so the lack of explicit exclusions is acceptable.

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 read-only nature, that nothing changes, how the destination is resolved exactly like a quote, edge cases for suspended or wallet-less agents, and that signed quotes and escrowed sales keep their destination. This is unusually thorough for a query tool.

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

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

The definition is front-loaded with READ ONLY and the core query, and every sentence addresses a real edge case or usage rule. It is longer and denser than most tool descriptions, but the complexity of delegated-agent payout resolution justifies the length; only minor tightening is possible.

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

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

An output schema exists, so return values need not be explained. The description still covers account types, delegated views, pending requests, and resolution edge cases. For a 0-required-parameter read-only tool, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, and the description only repeats that slug optionally checks one template. It adds no syntax, format, or constraint details beyond the schema and the schema's own slug description. Baseline 3 is appropriate when the schema already documents the sole 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 read operation: listing which templates are paid to which wallet right now. It distinguishes itself from the sibling set_payout_wallet by noting that it changes nothing and that changes go through set_payout_wallet. An agent can immediately tell what this tool does without opening the schema.

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

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

It explicitly covers who sees what (delegated agent, person, agent account) and provides clear when-to-use context via the optional slug. It also states the when-not condition by directing destination changes to set_payout_wallet. Alternatives and scope are fully 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?

With no annotations, the description carries the full behavioral burden, and it does substantial work: it enumerates the returned fields (email, name, handle, language, ownerWallet, payerWallet, accountType, isSeller) and, crucially, discloses the semantic constraint that ownerWallet is present but 'YOU cannot use to pay' while yours arrives in payerWallet and agentWallet is absent. It does not state read-only/auth/rate-limit behavior, but for a no-arg read tool that is 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?

Front-loads the core statement of purpose before the exclusions, and every clause carries routing or field information. Slightly weakened by the dense wallet clauses ('Yours comes right here in payerWallet, as in my_capabilities and my_balance'), which are harder to parse than the rest.

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?

An output schema exists, so raw return values need not be re-explained; the description instead supplies the semantic meaning of ambiguous fields (accountType for a delegate, the wallet distinctions). Combined with the explicit sibling routing, an agent has everything needed to call and interpret this tool.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There are no argument semantics to add meaning to, and the description correctly spends its words on return content and sibling differentiation instead.

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 resource ('YOUR OWNER's PROFILE DATA') and explicitly frames what the tool is for ('the tool to pick when what you need is the data that account presents itself with'). It distinguishes itself from close siblings by naming my_capabilities and my_balance and explaining the boundary, so an agent can select it without opening any schema.

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

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

Explicit when-to-use ('the tool to pick when...') plus multiple when-NOT clauses routing to named alternatives: scopes/sell-today go to my_capabilities, balances go to my_balance. This is textbook three-way routing with no inference required.

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. It specifies what data is returned (percentage, scope, validity, sales count) but does not explicitly state that the operation is read-only or safe, nor does it mention potential limitations like pagination, filtering by active/inactive, or ordering. The verb 'Lists' implies non-mutation, but the behavioral profile is only partially 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?

The description is a single, efficient sentence that front-loads the main verb and resource, then lists the key output attributes. No wasted words or redundant details, making it easy to scan.

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

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

Given the simple nature (0 params, output schema present, no annotations), the description covers the essential information: what is listed and what fields are included. It falls short of full completeness only by not clarifying whether inactive discounts are included or if any implicit filtering/ordering applies, but this is a minor gap for such a straightforward listing tool.

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

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

The tool has zero parameters and the schema coverage is 100% (an empty schema). The description doesn't need to explain parameters, so the baseline 4 applies. It adds no parameter-related confusion and correctly focuses on output content.

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 ('Lists') and resource ('your discount codes'), and enumerates the included data fields (percentage, scope, validity, paid sales usage). This distinguishes it from siblings like create_promo_code and set_promo_code_active, which mutate codes rather than list 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?

There is no explicit guidance on when to use this tool versus alternatives. It doesn't mention that it's appropriate for reviewing existing codes or that it should not be used for creating/updating them. The context signal of sibling names implies the distinction, but the description itself offers no routing 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?

No annotations are provided, so the description must carry behavioral disclosure. It conveys that the operation is a read-only list and that each purchase has a state, but it does not describe possible state values, ordering, pagination, or whether only completed purchases are included. This is acceptable for a simple list but not richly 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?

One short sentence with no filler. It front-loads the resource and the action, and every word contributes to the agent's understanding.

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 zero parameters and the presence of an output schema, the description is sufficient to invoke the tool correctly. The word 'state' is slightly under-specified, but because an output schema exists, the description does not need to enumerate return fields or state values.

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

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

The tool has zero parameters and the schema is fully covered (100%), so the baseline of 4 applies. The description adds the only meaningful semantic context: purchases are scoped to the account and include their state, which is genuinely useful beyond the empty schema.

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

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

The description clearly identifies the resource ('the account's purchases') and states what is returned ('their state'), using the verb 'Lists' to indicate read-only retrieval. It does not explicitly distinguish from close siblings like my_sales or my_cart, but the account-scoped 'purchases' resource is unambiguous enough for selection.

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 use when the caller needs a list of purchases for the current account, but gives no explicit conditions, exclusions, or alternatives. With many account-related sibling tools, an agent must infer when this one is the right choice rather than being told.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that the tool returns a code, a link, and stats, and that this occurs only when the programme is active. However, it does not explain what happens when the programme is inactive, whether authentication is required, or whether the returned link is ever missing or null. This is a partial but not complete behavioral picture.

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, efficient sentence that front-loads the return resource and includes the only relevant conditional qualifier. Every word contributes meaning, and there is no unnecessary repetition or filler.

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

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

For a zero-parameter, simple read-style tool with an output schema present, the description is largely complete: it names what is returned and includes the key activation condition. The main omission is the behavior when the programme is inactive, but given the tool's low complexity and the presence of an output schema, this is a minor gap rather than a fatal one.

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

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

The tool has zero parameters, and the schema coverage is trivially 100%. The baseline for no-parameter tools is 4, and the description adds nothing about parameters because none exist. No parameter documentation is needed here.

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 ('Returns'), a clear resource ('your referral code and link'), and an additional output detail ('with their stats'). It also adds the condition 'when the programme is active,' which distinguishes this tool's behavior from a generic referral lookup and makes its purpose unmistakable.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, and provides no exclusions beyond the vague note about the programme being active. Since the tool has no direct sibling named similarly, the description could have clarified the intended scenario, such as retrieving the caller's own referral details, but it leaves that 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, so the description carries the full burden. It usefully explains that authorIsAgent flags agent-written reviews and how they are labelled, but says nothing about permissions (must be the builder), ordering, or read-only nature. Adding the field semantics earns partial credit over a bare listing.

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 tight sentences with the scoping statement front-loaded. The second sentence is arguably return-value detail that the output schema already covers, but it is short and informative.

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?

An output schema exists, so return structure need not be explained, and both parameters are fully documented. What is missing is the usage boundary against sibling review tools and any permission context, leaving it adequate but with 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 100% — page (20 per page, default 1) and rating (exact stars 1-5) are fully documented in the schema. The description adds nothing beyond that, 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?

States a specific verb and a precise scope: reviews received by the builder's own templates, as opposed to reviews on a single template. It does not name the sibling it contrasts with (template_reviews), so differentiation is inferable rather than explicit.

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 when-to-use guidance and no mention of the close alternatives template_reviews or reply_to_review. The agent must infer from the name alone that this is the builder-side aggregate listing rather than a per-template view.

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 usefully discloses what each sale record contains (orderId, canRefund, blockedReason), but says nothing about auth/permission requirements, pagination beyond the limit param, or whether this is a read-only operation, which an agent would want confirmed.

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 tight sentences with zero filler, and the core purpose leads ahead of the per-record detail. Every clause 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, single-optional-param read tool with an output schema, this is nearly complete: the description covers purpose and the shape of the returned records, and the output schema handles field details. Only the lack of any usage routing or operation-safety note holds it back.

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 the single limit parameter is fully documented in the schema (range 1-200, default 50). The description adds no parameter-level meaning, so the baseline 3 for schema-documented params 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 verb and resource ('Lists the builder's sales') plus the scope of what's returned (state and settlement). 'Builder's sales' implicitly separates it from buyer-side siblings like my_purchases, but no sibling is named explicitly, which is the only thing keeping this from a 5.

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 rather than stated: an agent can infer this is the seller-side listing tool, but the description never says when to reach for it over closely related siblings such as my_purchases, order_status, or refund_sale. No exclusions or prerequisites are given.

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 well: it enumerates and explains every review state, the rejection note, catalog visibility, the three distinct price fields and their null semantics, the `found = false` outcome for missing/foreign slugs, and the long-description truncation behavior with its length fields. It omits permission/scope requirements (only implicitly contrasting with `template_details`'s read scope), which is the one meaningful gap.

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

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

It is front-loaded with the list behavior, but delivered as a single sprawling sentence with nested parentheses and scattered ALL-CAPS emphasis, and it repeats the slug mode that the schema already documents. The information is dense and largely useful, yet the structure is far from tight.

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-mode, zero-required-parameter tool this covers both modes, the enumeration of states, the price-field distinctions, the truncation trade-off and the not-found case. An output schema exists, so the extra return-value detail is a bonus rather than a necessity, and nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, and the description's `slug` and `fullDescription` explanations largely restate the schema text (translated slug works, full description added with the flag, preview + char counts without it). It adds the framing that copying the description is impractical at 'tens of thousands of characters', but this is marginal over an already-complete schema; 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?

States a specific verb and resource ('Lists your templates') plus the two operating modes (list vs. single-template full listing via `slug`), and explicitly differentiates itself from the sibling `template_details` by noting the latter only resolves published templates. An agent can pick between them without opening either schema.

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

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

Gives explicit routing guidance: use this (not `template_details`) when the goal is checking a submission, regardless of whether it is published, under review, rejected, unlisted or retired, and use `slug` when a single full listing is wanted. Alternatives and their selecting conditions are named directly.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that no dispute exists until the returned calldata is signed and mined, that the agent must sign with its linked wallet, that the owner files evidence separately, and that polling dispute_status requires a read scope.

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?

It is a single dense but front-loaded paragraph where each clause adds a distinct behavioral fact (buyer-only, signed calldata, not yet mined, owner files evidence, poll status). It could be broken into shorter units for scanability but contains no filler.

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

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

Given an output schema exists, the description need not detail return values, and it instead focuses on the signing workflow and follow-up status polling, which is the right emphasis. It is largely complete for a two-parameter mutation tool.

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

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

Schema description coverage is 100%, so the schema already documents both orderId (uuid escrow order) and reason (10-2000 chars, first evidence). The description reinforces that reason is the written case statement but adds no syntax or format detail beyond the schema.

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

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

It states a specific verb (open a dispute) on a specific resource (an order YOU paid), and clarifies the on-chain identity of the buyer. This cleanly distinguishes it from adjacent siblings such as dispute_status, withdraw_dispute, and close_expired_dispute.

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

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

It gives a clear precondition (only the buyer of the order can open it) and routes the agent to dispute_status for follow-up. It does not, however, contrast this with alternatives like withdraw_dispute or close_expired_dispute, so the when-not case is left 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 burden and does disclose meaningful traits: it surfaces both database and on-chain state, states that owner-paid orders are excluded and immovable, and notes download is enabled once the deposit is confirmed. Auth/rate-limit behavior and the exact 'next step' semantics remain implicit, preventing a 5.

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

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

Front-loads the resource and its states, then parameter behavior, then ownership caveats. Dense but each sentence carries distinct information; only the ownership/download clause is slightly extended.

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

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

With an output schema present, return values need no explanation, and the description adds the scoping and ownership constraints an agent needs. It is complete for this read tool, with only auth/permission details left unstated.

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

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

Schema coverage is 100%, so the schema already documents both txHash and orderId. The description restates the orderId no-argument behavior ('Without orderId it lists your active ones'), which adds little beyond the schema entry, 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?

States a specific verb+resource ('State of an order YOU paid') and enumerates the possible states (no deposit, in escrow, released, refunded, disputed), which lets an agent distinguish it from dispute_status and my_purchases. It does not name a sibling explicitly, keeping it just below the top tier.

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?

Explains the calling modes: with orderId to inspect one order, without it to list active ones, and it clearly excludes owner-paid web orders and notes the agent 'cannot move them.' This gives clear context for when each mode applies, though it does not route to an alternative tool by name.

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

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

With no annotations, the description carries the full burden and discharges it: it states nobody signs in the browser, the MCP never signs nor moves funds, refunds return to the agent's wallet, only the agent can open/withdraw the dispute, and new accounts may hit a wallet limit. These are exactly the behavioral traits an agent cannot infer from 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 'SPENDING:' label front-loads the core action, but the body is a dense run-on that mixes scope, ownership, payment routing, disputes, and dry-run caveats with heavy overlap on the schema's param text. Much earns its place, yet the wall-of-text format hurts scannability.

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?

An output schema exists, so return values need not be explained. For a complex spending/mutation tool with no annotations, the description covers ownership, signing, funds movement, refunds, dispute rights, and dry-run behavior, leaving only minor gaps around quota/limit edge cases.

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

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

Schema coverage is 100% and the schema's own parameter descriptions are already unusually rich (dryRun, confirm, quoteId semantics fully spelled out). The description reiterates the confirm=true requirement and dryRun intent but adds little parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource ('creates the purchase order ON BEHALF OF YOUR OWNER') and immediately scopes it against alternatives ('leaves it ready for YOU to pay ... using deposit_data'). An agent can distinguish this from quote_purchase, link_wallet, and deposit_data without opening any schema.

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

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

It names the prerequisite flow explicitly ('requires confirm=true after checking the total with quote_purchase'), routes the payment step to link_wallet/deposit_data, and routes post-purchase actions to open_dispute/withdraw_dispute. When and how to use it is fully specified rather than inferred.

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

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

With no annotations, the description carries the full burden and does so: it discloses that no order is created, that the quoteId is a fingerprint of that specific total, that a stale total causes refusal rather than a wrong-amount purchase, and that nothing is reserved and the promo code is not consumed. These are exactly the side-effect facts an agent needs before calling.

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

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

Four short sentences, front-loaded with what the tool does, then the quoteId contract, then the routing to prepare_payment, then the side-effect caveats. Every sentence carries information an agent acts on; no filler.

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

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

The output schema exists, so return values need no explanation, yet the description still explains what the quoteId is for. Combined with the no-side-effects disclosure and the refusal-on-changed-total behavior, an agent has everything needed to call it and use the result correctly.

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

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

Schema description coverage is 100%, so the two params (slug, promoCode) are already documented and the baseline is 3. The description adds real semantic value for promoCode by clarifying that the quote does not consume it, which affects whether an agent can safely re-quote.

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+resource: it computes the final price and breakdown of a purchase without creating the order, and returns a quoteId. It also distinguishes itself from the sibling prepare_payment by naming where its output goes.

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 tells the agent exactly when to use this tool (to see a total before buying) and routes to the alternative: hand the quoteId to prepare_payment to buy exactly what was shown. It also states the negative case — the purchase is refused if the total changed — so nothing is left 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 delivers: irreversibility ('cannot be undone'), the full-amount payout, that the buyer loses the download, the escrow/dispute/deadline gates, the two signing paths, and that the agent must pay gas. This is exactly the behavioral context an agent needs before an irreversible mutation.

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

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

Front-loaded with the core purpose, then branches cleanly by signing path, then lists constraints. It is dense and heavy on ALL-CAPS emphasis, but nearly every clause carries operational weight, so the length is largely justified.

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 3-parameter irreversible mutation with an output schema present, the description covers preconditions, side effects, both execution branches, and the confirmation handshake. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents txHash, confirm, and orderId in detail. The description restates rather than extends that meaning, so the baseline 3 applies; the workflow framing around txHash and confirm is already present in the 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?

States a specific verb and resource ('Voluntary refund of one of your owner's sales') and immediately disambiguates the two execution paths based on whether the agent's own wallet is the payout destination. An agent can tell exactly what this tool accomplishes and where it sits relative to the signing-in-My-sales flow without opening any schema.

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

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

Explicit preconditions are given: 'only possible while the payment is still in escrow, with NO open dispute and BEFORE the deadline expires,' plus routing rules for who must sign. It does not name a sibling tool alternative, but no true alternative exists for this operation, so the guidance is effectively complete for the decision.

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 signaling mutation; 'removes' does communicate a destructive side effect. However, it does not disclose idempotency, behavior for a slug not in the cart, or reversibility, though these are somewhat implicit for a cart removal.

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 one short, front-loaded sentence with no filler; 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 one-parameter mutation with an output schema, the description is essentially sufficient: it names the action, the target, and the parameter is self-explanatory. It could add usage caveats, but nothing critical is missing at this complexity level.

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 'slug' is already documented as 'Slug of the template to remove.' The tool description adds no additional parameter meaning beyond confirming the singular operation.

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 ('Removes a template') on a specific resource ('the cart'), making the intent unmistakable and clearly different from sibling operations like add_to_cart and my_cart.

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 verb 'removes' implies when to use it (when deleting a template from the cart), but there is no explicit guidance about prerequisites, such as the template needing to be in the cart, nor an explicit contrast with add_to_cart/my_cart.

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 discloses real behavioral traits: text-only (no file uploads through this tool; files come from the browser), the case must be open, and on a dispute only the opener may post. It does not cover auth requirements, error behavior on a closed case, or rate limits, so it is strong but not exhaustive.

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

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

Two tight sentences with the core action front-loaded and the constraints appended; every clause carries meaning and nothing is padded.

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 post action the description covers ownership, case state, and the text-only limitation, and an output schema exists to explain the return. Only minor gaps (failure behavior on closed cases, no alternative routing) remain.

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

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

Schema coverage is 100%: text (1-10000 chars) and caseId (sourced from my_cases) are already documented. The description only reinforces the text-only constraint and does not add format or syntax detail 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?

States a specific verb (posts a message) and resource (one of YOUR cases), and adds the preconditions that the case be open and, for disputes, that the caller be the opener. An agent can distinguish this from submit_evidence or open_dispute without opening any schema. It stops short of naming an alternative sibling explicitly, so it is clear but not sibling-routed.

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 constraints 'still open' and 'only whoever opened it' imply when the call is valid, but there is no explicit when-to-use vs when-not guidance (e.g., message here vs attach files via evidence_upload_link/submit_evidence). Usage is implied rather than 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?

With no annotations, the description carries the full behavioral burden. It discloses the meaningful trait that replies are moderated, and the schema adds the one-time-only constraint, but nothing is said about auth requirements, what happens after moderation, or whether the reply is publicly visible.

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 zero wasted words; the verb and object come immediately. It is efficient, though arguably terse for a moderated publish action.

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

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

An output schema exists, so return values need not be explained, and the schema fully covers both params. However, for a mutation tool with no annotations and no usage guidance, the description leaves the moderation workflow and post-publish behavior unexplained.

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

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

Schema description coverage is 100%: both params are documented with length limits, one-time constraint, and where reviewId originates. The description adds no parameter meaning beyond that, 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?

States a specific verb ("Publishes") and resource ("the builder's reply to a review"), so the operation is unambiguous. It does not explicitly distinguish itself from the sibling reply_to_case, but the resource differs clearly enough that an agent can route correctly.

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 when-to-use guidance, no prerequisites, and names no alternatives. The only hint of context ("from my_reviews") lives in the schema's reviewId field, not in the description itself.

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

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

No annotations are provided, so the description carries the full burden. It does not say where the report goes, whether it needs authentication, whether it is rate-limited or acknowledged, or what happens after submission — significant gaps for a mutation tool with zero annotation coverage.

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 — efficient and appropriately sized. It is arguably too terse for the amount of unspecified behavior, but nothing in it is wasted.

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 output schema exists, so return values need not be explained, and the schema fully covers both parameters. However, with no annotations and a mutation-style tool, the description omits any account of side effects, handling, or follow-up — it is not complete enough for confident 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% (both 'page' and 'message' are documented in-schema), so the baseline is 3. The parenthetical '(10 characters minimum)' restates part of the schema's 10-2000 character rule without adding new meaning, so no credit above baseline.

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

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

States a specific verb and resource ('Reports a platform bug to the team'), so the intent is unambiguous. None of the ~55 sibling tools overlap with bug reporting (they are all cart, template, dispute, wallet or profile operations), so sibling differentiation is implicit rather than stated.

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 when-to-use context, no prerequisites, and no routing to alternatives such as search_help or reply_to_case. An agent knows what the tool does but not when it is the right call versus existing support paths.

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

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

With no annotations, the description carries the full burden and does so: it discloses that the licence cannot change, that an EXCLUSIVE_SOLD template is permanently ineligible, the MEMBERSHIP_REQUIRED selling prerequisite, that the edit draft is discarded on resubmission, and exactly what dryRun skips (quota, family lock, pre-filter, ZIP provenance). This is unusually complete for a mutation tool.

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

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

Long, but front-loaded: the core action and the partial-update contract open the description, followed by eligibility rules, then useDraft, then dryRun. Each sentence conveys a distinct constraint or failure mode, and error codes are attached inline where they belong.

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 mutation with nested objects and an output schema (so return values need no explanation), the description covers prerequisites, irreversibility, draft handling, dry-run semantics and the error codes an agent will encounter. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: useDraft's draft-selection and precedence over fixes, dryRun's no-side-effect guarantee, and the warranty object's restriction to wallet-born agent accounts with a new file. It doesn't add much for slug/file since the schema already documents those thoroughly.

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 precise verb and resource: fixing one of YOUR templates that the review REJECTED and sending it back to the queue. It clearly separates this from new-submission flow ('the same as when publishing'), so an agent can distinguish it from submit_for_review without opening the schema.

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

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

Explains the triggering condition (your template was rejected), the partial-update contract ('send only the fields that change'), and two modes (useDraft, dryRun) with the conditions that select them. It also notes the alternative rehearsal path (check_before_submit for quota-consuming steps). It never names submit_for_review directly as the alternative for non-rejected templates, so it falls just short of explicit when-not-to-use 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?

With no annotations, the description carries the full burden and does so: irreversible, no reactivation, existing buyers retain downloads, confirmation required, and the non-obvious bond consequence (bondStatus = pending plus bondNote, committee decides). That bond edge case is exactly the kind of behavioral detail an agent could not derive from 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?

Front-loads the decisive fact (permanent retirement) in the first clause, then layers preconditions and the bond exception. Dense but mostly earning its place; the final sentence about lost disputes is long and could be split, though the information is genuinely non-obvious.

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 an irreversible mutation with no annotations, the description covers what is destroyed, what survives (existing buyers' downloads), the required confirmation, and the one exceptional return state. With an output schema present it correctly does not waste space explaining ordinary return values.

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

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

Schema coverage is 100% and both parameters are already documented, including the confirm=true requirement and its permanence warning. The description reinforces the confirmation semantics and adds the 'ask the person first' social guidance, but adds no new syntax or format meaning. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('RETIRES one of your templates') and immediately pins down the scope: leaves the catalog, takes no new sales, cannot be undone or reactivated. That permanence framing cleanly separates it from the reversible siblings set_template_active and update_published_template without naming 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?

Gives a clear precondition ('requires confirm=true; ask the person first') and an implied when-not: this is the permanent route rather than the deactivate/reactivate route. It never explicitly names an alternative tool, so the agent must infer that set_template_active is the non-destructive option.

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 disclosure burden. It usefully explains the two operating modes (search vs. full-article fetch by slug), but says nothing about auth requirements, rate limits, or result truncation. For a low-risk read tool this is tolerable, hence a middle score.

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 tight sentences, front-loaded with the core action and followed by the operational directive. Every clause carries information; nothing is padding.

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

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

With an output schema present, return values need not be described, and both parameters are fully documented in the schema. The description is complete for a simple read tool, missing only minor operational notes about limits or failure modes.

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

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

Schema coverage is 100%, so the baseline is 3, and the description genuinely adds meaning by explaining the interaction: passing a slug returns the full article instead of performing a search. This clarifies how the two parameters relate rather than merely restating them.

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 (searches) and resource (Bernuvia's help center), and additionally names the second mode (full-article retrieval by slug). No sibling tool covers help content, so it is unambiguously distinguishable from the rest of the catalog.

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

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

Gives an explicit directive on when to use it — 'BEFORE explaining how the platform works; do not invent rules' — which is a clear usage condition. It doesn't name an alternative tool, but none exists for this resource, so the guidance is adequate.

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 but only says what is searched, not how: no disclosure of pagination, result ordering, default scope (public vs. private catalog), or auth requirements. 'limit' exists in the schema but behavior around omitted queries or empty results is 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 front-loaded sentence with no wasted words; the searched fields are identified immediately. It is appropriately sized for a search tool, though borderline sparse.

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?

An output schema exists, so return values need not be described, and the schema fully documents parameters. What remains missing is catalog scope and result behavior, which an agent would want before relying on this instead of template_details or my_templates.

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

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

Schema description coverage is 100%, so all four parameters (q, limit, category, platform) are already documented in the schema. The description's mention of text/category/platform adds orientation but no syntax or formatting detail beyond the schema; 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?

States a specific verb (searches) plus resource (template catalog) and names the three search dimensions. It does not explicitly differentiate from sibling search-adjacent tools like my_templates or template_details, but the phrase 'the template catalog' implies the public catalog rather than the user's own templates.

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 on when to use this versus template_details (single template lookup) or my_templates (the caller's own templates). Usage is only implicitly inferable from the tool name and the mention of catalog search.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does well by disclosing that the membership link is for the owner, that the agent cannot sign it, and that a lapsed membership causes seller tools to stop answering. It stops short of explicitly stating 'this operation is read-only and has no side effects,' though that is strongly implied.

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, each earning its place: what the tool reports, who can perform membership actions, and the consequence of lapse. It is front-loaded with the core meaning and contains no filler.

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

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

For a parameterless informational tool with an output schema present, the description covers the essential context: membership state fields, ownership boundaries, agent limitations, and operational consequences. Nothing needed to correctly invoke this tool 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 the schema is trivially complete and there is nothing for the description to clarify. The baseline for zero parameters is 4, and the description does not need to add parameter-level information.

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 resource as the owner's seller membership and specifies the kind of information returned (price, next charge, latest payments). It does not use an explicit verb like 'retrieves' or 'checks', but the noun phrase 'The state of...' strongly implies a read-only status query and the description distinguishes this from membership management 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 description gives clear context for when to use this tool: to know the seller membership state that governs selling activity. It also explicitly says activation, changing, or cancellation is not this tool's business and cannot be signed by the agent, which is an effective exclusion. It doesn't name a specific alternative tool, but given the zero-parameter informational nature, that is acceptable.

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