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 carries the behavioral burden. It does convey a read-only operation ('Returns') and the scope of results, which is useful, but it does not disclose details such as whether stats are for the current authenticated builder, how lifetime totals are computed, or any access requirements.

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

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

The description is a single front-loaded sentence that begins with the action and resource, then packs the key metrics into a parenthetical list. There is no filler, repetition, or wasted wording.

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

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

An output schema is present, so the description does not need to explain return values in detail. Combined with full parameter documentation and default dates in the schema, the description covers the core behavior well; it is only missing a small amount of usage context relative to sibling 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%, so the schema already documents every parameter and the deprecated aliases. The description adds no parameter-level detail beyond what is in the schema, which is acceptable at the baseline of 3.

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

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

The description uses a specific verb ('Returns') and identifies a concrete resource: the builder's sales stats. It also enumerates the exact aggregation dimensions (count, gross, net, released, by day, by template) and lifetime totals, which clearly distinguishes it from a plain sales-list tool like my_sales.

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

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

The description states what the tool returns but gives no guidance on when to choose it over siblings such as my_sales, deposit_data, or my_balance. There are no explicit alternatives, exclusions, or contextual triggers, so an agent must infer usage from the tool name and shape alone.

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

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

With no annotations provided, the description fully carries behavioral disclosure. It reveals conditional returns (typedData without signature, calldata with signature, broadcast variant), that the server controls the authorizer, that the order only closes under a specific condition, and that already-used/cancelled authorizations are detected and reported.

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 paragraph, but every clause earns its place by explaining a distinct behavioral branch, security consideration, or edge case. The core purpose is front-loaded, and the length is justified by the genuine complexity of the operation.

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

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

For a 9-parameter tool with no annotations and multiple operational modes, the description covers the full decision space: identification routes, signature modes, broadcast behavior, order closure semantics, and already-used/cancelled outcomes. An agent has enough context to select parameters and interpret 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 coverage is 100%, so the baseline is 3, but the description adds meaningful usage semantics beyond the schema: where `nonce` comes from, why `nonce` is preferred over `cotizacion`, and how `signature` alters the return behavior. It does not redundantly re-explain every field, but it does not need to given the complete schema.

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

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

The description opens with a specific verb and resource: 'Withdraws a gasless-deposit authorization'. It clearly distinguishes this from related deposit operations by framing it as revocation of an already-issued authorization, not creation or submission.

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 explains when to use the `nonce` route versus the `orderId` + `cotizacion` route, including the caveat that `nonce` works even after a newer quote is requested. It also covers the choice between returning calldata for self-submission and using `broadcast`/`retransmitir` for Bernuvia to send 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 provided, the description carries the full burden and exceeds it: it declares the operation is side-effect-free, does not spend tokens, is advisory, never returns secret values or the matching catalog template, and explains the content filter's behavior and quota. It also discloses that it does not validate content legality, which is crucial for the agent to set expectations.

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 long but densely packed with high-value information. It front-loads the core purpose (dry run, no changes) and then systematically covers limitations, quotas, content filter, and return format. While some redundancy exists (e.g., repeated mention of advisory nature), every sentence contributes to a complete understanding, so it earns a high score, though not a 5 due to slight verbosity.

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

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

Given the tool's complexity (dual validation of ZIP and listing, content filter, quotas, deprecated aliases), the description is remarkably complete. It covers side effects, return content (problems with category, file/field, fix, codes), resource consumption, and even references the output schema. There is nothing an agent needs to know to call it correctly that 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 schema already has rich per-property descriptions, but the tool description adds essential context beyond the schema: it explains the file must be from a prior upload (uploadToken tied to the account), the template is optional and mirrors submit_for_review fields, runContentFilter requires plantilla and only for agent accounts, and it mentions deprecated aliases (archivo, plantilla) that are in the schema. This adds meaning not present in the schema alone.

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

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

The description clearly states it is a dry-run validation tool for a previously uploaded ZIP and an optional listing, explicitly contrasting with the real submission (submit_for_review). It names the resource (ZIP from zip_upload_link), the validation aspects (size, type, secrets, licences, similarity, required fields), and the advisory nature, leaving no ambiguity about its function.

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 positions this tool as the pre-submission dry-run, tells the agent it does not spend the uploadToken or other submission resources, and clarifies when the content filter applies (agent accounts with runContentFilter: true). It also states what it does NOT judge (content legality), routing to the Content policy and legal_versions, and mentions its own hourly cap, so the agent knows when to call it and what to expect.

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 does so thoroughly: it explains deadline semantics, full-amount/no-fee crediting to the caller's escrow wallet, the need to call withdraw() afterward, and the prohibition on withdrawing the owner's money. It also notes what the rejection tells you when the deadline has not expired.

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 dense paragraph but is front-loaded with the eligibility condition and every sentence contributes operational detail. It is longer than strictly minimal, yet the length is justified by the complex contract interaction being described.

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

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

Given no annotations and a nontrivial escrow operation, the description covers when to use it, how to confirm the deadline, what outcome to expect, and the follow-up withdraw action. The output schema exists, so the absence of return-value explanation is not a 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 description coverage is 100%, so the schema already documents orderId and the deprecated ordenId alias. The description only restates orderId in the calldata signature and adds no new parameter-level meaning, so the baseline score 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 identifies a precise action (resolveDisputeByTimeout(orderId) calldata), the target resource (the escrow contract), and the triggering condition (deadline expired without resolution). This is specific enough to distinguish the tool from siblings like open_dispute and withdraw_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 an explicit 'Only when' condition and explains how to verify the deadline via dispute_status, including the possibility of extension. It does not name sibling alternatives, but the condition is clear and actionable.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses the key non-obvious behavior: the call fails if a draft already exists, implying it never overwrites. It does not mention broader lifecycle details such as auth or where the draft appears afterward, but the critical failure mode is 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?

The description is three tight sentences. The failure condition is front-loaded, then the schema pointer, then a clear statement that nothing else is required. Every sentence earns its place and there is no filler.

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

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

Despite having 18 parameters, the input schema is extremely detailed and the tool has an output schema, so the description does not need to re-explain fields or return values. It supplies what the schema cannot: the failure-if-exists behavior, sibling routing, and the reassurance that anything not in the schema is not required. This is complete for the agent to call it correctly.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds useful cross-parameter context above that baseline: gallery and bannerUrl must use paths from image_upload_link, category and platforms are closed lowercase lists, price must be a number, and licenseType is standard or exclusive. This helps the agent understand recurring constraints without duplicating the schema.

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

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

The description uses a specific verb and resource: 'Creates the publish draft'. It also distinguishes itself from siblings by stating that it fails if a draft already exists, and names update_draft and delete_draft as the alternatives. This makes the tool's purpose and scope unambiguous.

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

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

It explicitly tells the agent what to do when a draft already exists: 'carry on with update_draft or delete it with delete_draft'. It also directs the agent to rely on the input schema for values and limits, and clarifies that no external article or prerequisite is needed.

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 provided, so the description carries full burden. It discloses irreversible consequences (name taken for good, gives away margin), requires explicit confirmation (confirmar=true), and limits scope to named templates. This is excellent transparency for a mutating operation.

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

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

The description is two sentences, front-loaded with the core purpose and constraints, and the confirmation requirement is placed second. It is efficient, though slightly dense with mixed content (format, limits, and behavioral warnings) that could benefit from bullet points for clarity.

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

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

Given the tool's complexity (12 params, aliases, deprecated fields), the description covers all essential aspects: input format, constraints, confirmation requirement, and consequences. The output schema exists, so return value details aren't needed. No critical information 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. The description adds critical meaning beyond the schema: it explains why confirm is required ('gives away margin' and 'name is taken for good'), which is not evident from the schema alone. This compensates for the schema's dry specifications and justifies a 4.

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

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

The description clearly states the action (creates a discount code), the target (your templates), and key constraints (3-24 chars, 1-90%, max 10 codes per template). It distinguishes from siblings like my_promo_codes (viewing) and set_promo_code_active (toggling) by implying this is for creation.

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

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

The description explicitly states the primary use case (creating codes for your templates) and a constraint (at most 10 codes per template). It implicitly excludes catalog-wide codes via the schema note but doesn't name sibling alternatives like set_promo_code_active for toggling.

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

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

With no annotations provided, the description carries the full burden and does so well: it states that the operation is destructive, cannot be undone, requires confirmation, and that drafts are one per account. It also flags the sensitive edit-draft case, which is exactly the behavioral context an agent needs.

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

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

The description is three tight sentences with no filler: the action and one-per-account fact are front-loaded, followed by irreversibility, user confirmation guidance, and the create_draft relationship. Every sentence earns its place.

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

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

For a destructive mutation tool, the description is complete: it covers what gets deleted, the single-draft constraint, confirmation requirements, irreversibility, and the appropriate pre-check workflow with my_draft. Since an output schema exists, return-value details are not 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?

Schema description coverage is 100%, so the schema already documents the confirm/confirmar parameters in detail. The description reinforces that confirmation is required and irreversible, but adds little semantic value beyond what the schema provides.

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

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

The description states a specific verb and resource: it DELETES the saved publish draft, and clarifies the one-per-account constraint. This lets an agent clearly distinguish deletion from related operations like create_draft, update_draft, or 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?

The description explicitly instructs the agent to show the draft with my_draft and ask the user before deleting, especially for EDIT drafts. It also explains the relationship to create_draft, giving clear when-and-how guidance and naming the relevant sibling tools.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains who signs and sends, who owns the resulting purchase, who does not pay gas, the legal acceptance of terms, the waiver of the 14-day withdrawal right, and the gasless path's extra EIP-3009 authorization. This is exceptionally transparent about non-obvious consequences.

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?

Five dense sentences, front-loaded with purpose and signer constraints. The legal waiver, gas responsibility, and gasless variant are all necessary for correct use. It is somewhat long, but every sentence contributes; the structure is appropriate for the complexity.

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

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

The description covers the prerequisite order, signer and wallet requirements, ownership effects, gas-cost location, legal acceptance, and gasless routing. Combined with a rich input schema and output schema, an agent has enough to call it correctly; only auxiliary details like how to confirm platform support are left to other 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 coverage is 100% and every property already has thorough descriptions, including deprecated aliases and phase-6 conditions. The top-level description reinforces orderId's origin and the legal meaning of completing a deposit, but it adds little parameter-level meaning beyond what the input schema already provides.

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

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

The description opens with 'DEPOSIT' and immediately states what the tool does: it returns the quote signed by Bernuvia and the calldata for USDC approve and fundPurchase. It clearly identifies the resource (an order created with prepare_payment), the action (returns signing/sending payloads), and the distinction from the sibling submit_signed_deposit.

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 explicitly anchored to an order created with prepare_payment. The description contrasts the classic path (you sign and send, Bernuvia does not pay gas) with the gasless variant (singleSignature=true → call submit_signed_deposit), and imposes the linked-wallet/msg.sender and wallet-no-code conditions. This gives the agent clear routing between alternatives.

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

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

With no annotations, the description carries the full burden and states that this is a read-only operation: 'The seller only reads status and deadlines: no thread, no evidence, no actions.' It also discloses what the response reports (deadlines, reopenings, decision, execution), even though an output schema exists.

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

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

The description is longer than average, but almost every sentence earns its place: selection criteria, exclusions, and behavior. The enumeration of returned fields is slightly redundant with the output schema, but it is still organized and front-loaded with the core purpose.

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

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

The description covers the required parameter, selection context, exclusion of siblings, and the read-only nature of the call. Combined with a full input schema and an output schema, an agent has everything needed to choose and invoke this tool correctly.

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

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

The schema already provides 100% parameter coverage with detailed descriptions of orderId and the deprecated ordenId alias. The description only says 'asked for by order id,' which adds no meaningful information beyond the schema, so the baseline 3 is appropriate.

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

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

The description names a clear verb+resource combination: retrieving the status and deadlines of one order's dispute by order id. It explicitly distinguishes itself from siblings (my_cases, my_evidence) rather than merely restating the tool name.

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

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

It gives an explicit selection condition: use when you already know which order you mean and need the clock and next step. It also tells when not to use it, naming the alternatives for case lists and evidence files, leaving no ambiguity.

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

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

With no annotations provided, the description carries the full burden, and it does disclose important behavior: the link is temporary (10 minutes) and includes a SHA-256 checksum for verification. It does not mention failure modes or whether issuing a new link invalidates a previous one, but the disclosed traits are substantive.

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

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

The description is a single front-loaded sentence with no filler. It packs the essential facts—temporary link, duration, prerequisite, and checksum—into a compact and immediately actionable form.

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

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

The description plus a rich schema and an output schema cover the essential agent needs: what the tool does, the ID to supply, and the link's validity period. It does not spell out error behavior for unpaid purchases or authentication requirements, but for a two-parameter tool this is a minor gap.

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

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

Schema description coverage is 100%, and the schema itself already documents purchaseId and compraId, including the deprecated alias and the warning not to use ordenId. The tool description adds no parameter-level detail beyond the paid-purchase context, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Issues') and a specific resource ('temporary download link for a purchase already paid'), and adds the distinguishing detail of a SHA-256 checksum. It is immediately clear this is the download counterpart to upload-focused siblings like evidence_upload_link and zip_upload_link.

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

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

The description states the key precondition: the purchase must already be paid. The schema further clarifies which identifier to use by warning against the ordenId from prepare_payment. It does not explicitly name alternatives or say when not to use the tool, but the qualifying condition is clear enough for correct 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 behavioral disclosure burden, and it does so well: it states the 1-hour expiry, the storageRef return value, count semantics, buyer-only authorization, accepted formats, size cap, and that the answer reports how many links were issued and their expiry. It does not explicitly label the operation as non-mutating or describe error cases, but the observable behavior relevant to an agent is 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?

The description is dense but every sentence earns its place: purpose, output contract, count behavior, authorization, and constraints. It is front-loaded with the core action and resource, and the longer length is justified by the tool's conditional parameters and security context.

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?

All call-construction facts are present: required identifiers (orderId/ordenId and type/tipo), optional count, accepted media types, size limit, buyer-only authorization, and how the result feeds into submit_evidence. Since an output schema exists, the response shape does not need to be repeated in prose.

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 each parameter is already documented in detail, including deprecated aliases. The description adds cross-parameter meaning: `count` issues several links of the same `tipo`, `tipo` represents an evidence-file grouping, and the returned storageRef is exactly what submit_evidence expects. This lifts it above the schema-only baseline.

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

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

The description states a specific verb and resource: it issues presigned URLs for uploading evidence files (screenshots or PDFs) in the dispute of an order. It clearly ties the return value (storageRef) to submit_evidence, and the dispute-evidence context distinguishes it from generic upload sibling 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 explains when to use the tool: before submitting evidence in an order dispute, by the buyer of the order, with explicit file-type and size limits. It also advises using `count` for multiple screenshots and one call per type when mixing types. It does not explicitly name image_upload_link or zip_upload_link as alternatives, so it stops short of full when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, and it does so thoroughly: presigned URLs expire in 1 hour, the HTTP method is PUT, the server rejects non-conforming images on submit, the server neither converts nor crops, dimension/ratio tolerance is specified, and the description's ratio is not enforced. This goes well beyond the input schema and gives an agent an accurate mental model of the behavior.

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

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

The description is dense and front-loaded, starting with the core action before moving to requirements, constraints, and exclusions. Every sentence conveys a distinct requirement and none is filler, though the paragraph is long and the all-caps phrases make it less polished than it could be.

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 nuanced upload tool with no annotations, this description is remarkably complete: it covers URL expiry, HTTP method, accepted format, aspect ratio tolerance, recommended dimensions, maximum size, conversion command, rejection behavior and error code, where the path is valid, where constraints are not enforced, and the alternative for videos. An output schema is present, so the return-value description is sufficient without enumerating fields.

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 only parameter, count, is already fully documented in the schema with type, range (1-21), and default (1), and schema coverage is 100%. The description merely repeats 'Ask for several at once with count', adding no meaningful semantic detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a precise verb and resource: it issues presigned URLs for PUT-ing WebP images and returns each one's path. It further narrows the purpose by stating which fields the path works in (gallery, bannerUrl, inline description) and by explicitly excluding videos, which differentiates it from sibling upload tools like evidence_upload_link and zip_upload_link.

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

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

The description gives clear context for when to use the tool: for WebP images intended for gallery, banner, or description placement, with the count parameter for batching. It also provides a when-not case ('Videos do NOT go through here') and points to the alternative mechanism (YouTube links in youtubeLinks). It does not explicitly contrast with the other upload sibling tools, but the domain is sufficiently clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the one-time irreversible nature, the fact that it never withdraws the owner's money, the signing flow (challenge, no gas), and the downstream consequences for payments and refunds. This is rich behavioral context beyond what the schema shows.

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 dense and front-loaded with the most important constraint (one-time, own wallet). Every sentence adds information, though the capitalization and run-on structure make it slightly harder to parse. It's longer than ideal but each 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?

The description covers the purpose, the one-time constraint, the payment/refund implications, the relationship to sibling tools, and the safety guarantee. With an output schema present and 100% parameter coverage, nothing critical is missing for an agent to decide whether and how to call 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?

Schema coverage is 100%, so the baseline is 3. The description adds context about the two-step challenge flow (nonce from step 1, signature of the mensaje), which clarifies how the parameters relate to each other. It doesn't add syntax details beyond the schema, but the flow explanation adds meaningful value.

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

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

The description clearly states the tool links the agent's own wallet via a signed challenge, with no gas. It explicitly distinguishes from the owner's in-app wallet and names the one-time constraint. The verb 'links' plus the resource 'wallet' and the proof-of-control mechanism make the purpose unmistakable.

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

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

The description explicitly says it can only be done once, that the wallet becomes the paying wallet for purchases and collects sales, and that the only way out is creating another agent. It also references sibling tools set_payout_wallet and refund_sale, giving clear context for when this tool is relevant.

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

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

No annotations are present, so the description carries the full disclosure burden. It states the tool is read-only, cannot withdraw/spend, clarifies owner vs agent wallet semantics, explains canSell as a daily sell eligibility flag, and warns about deprecated aliases wallet/isSeller. This goes well beyond what a bare schema would convey and contradicts nothing.

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

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

The description is front-loaded with purpose and usage guidance and every section carries information, but it is verbose and somewhat redundant, for example restating read-only as 'you can neither withdraw nor spend it' and using emphatic caps that add noise. A tighter rewrite would preserve the useful details with less 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 zero-parameter read-only tool with an output schema, the description is complete: it identifies the owner vs agent distinction, spendability limits, deprecated aliases, and the correct sibling tools. No essential calling context appears to be 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?

There are zero input parameters, so the baseline is 4 and no input semantics are needed. The description instead adds meaning to returned fields such as ownerWallet, payerWallet, agentWallet, and canSell, which is useful despite not being input-parameter documentation.

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

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

The description states a specific verb and resource: it returns the balance/figures of the owner's account (wallet plus escrow). It differentiates itself from siblings by naming my_capabilities and my_profile as the tools for scopes and profile data, and by declaring it is the only account tool that returns figures.

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 exclusions and alternative routing: do not use for scopes/credential type (use my_capabilities) and do not use for owner profile data (use my_profile). The positive use case is implied clearly: use when you need wallet/escrow balance figures.

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 provided, the description carries the full transparency burden, and it does well: it discloses that there is exactly one draft per account, that it is shared with another assistant, that `missing` comes from the same validation the submission runs, and that fields use the same vocabulary as create_draft/update_draft. It does not cover edge cases like what happens when no draft exists or whether the call has side effects, but the read-oriented verb “Returns” provides reasonable confidence that this is a non-mutating operation.

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

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

The description is a compact, two-sentence paragraph with no filler: the primary result is front-loaded, the validation semantic is explained next, and the vocabulary detail is deferred to the final clause. Every sentence adds operational value, and code identifiers are used precisely.

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

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

For a zero-parameter read tool with an output schema present, the description is complete: it states what is returned, how to interpret `missing` and `readyToSubmit`, and what to do next after readiness. The missing edge-case notes (e.g., draft absent) are minor against the low complexity and the presence of an output schema.

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

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

The tool has zero parameters, so the input schema is trivially complete and there is little for the description to add about invocation arguments. The description instead adds semantic context about the shape of the returned data, such as prices as a number, licence limited to `standard` or `exclusive`, and videos as YouTube links. This is useful and goes beyond the empty schema, earning the baseline 4 for a no-parameter tool.

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: “Returns the saved publish draft” and immediately distinguishes this tool from siblings by clarifying it reports pre-submission readiness rather than creating, updating, or submitting. It explicitly names related tools (create_draft, update_draft, submit_for_review) and frames its role as the read-side counterpart to those 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 the tool: to inspect the current draft and the validation gaps it still needs before submission. It even routes the user to the next step by stating that when readyToSubmit is true, all that remains is uploading the ZIP and calling submit_for_review. It does not explicitly state “use update_draft when missing has items,” but the vocabulary reference implies how the output connects to update workflows.

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 communicates a read/check behavior ('pick it to check what the file already contains') and a strict buyer-only scope. It does not explicitly state 'read-only' or list possible empty results, but the wording strongly implies non-mutating inspection and an output schema handles return details.

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

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

The description is compact and front-loads the main purpose before exclusions. The ALL-CAPS opening and long sentence structure are somewhat stylistically noisy, but every clause adds necessary information.

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

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

For a read-oriented evidence lookup tool, the description covers purpose, scope, ownership restrictions, and sibling exclusions. With parameter schema at 100% coverage and an output schema present, nothing essential is missing for correct selection and 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 coverage is 100%, so the schema already documents orderId and the deprecated ordenId alias. The description only adds that the order is one 'you bought' and is disputed, which is useful context but not parameter-level semantics beyond the schema.

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

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

The description clearly states that the tool lists or inspects evidence the user filed for a disputed order, including dates. It explicitly distinguishes itself from dispute_status and my_cases, so an agent can tell exactly what resource this tool exposes.

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 direct when-not-to-use guidance by naming alternative tools for dispute status and case messages. It also enforces buyer-only and own-evidence scoping, which prevents misuse.

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 conveying behavior. It does indicate a read-only listing action and the 'favorites' filter, but it adds no detail about ordering, authentication, or potential empty results. This is adequate for a simple list tool but leaves behavioral nuance undisclosed.

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 entire description is a single, front-loaded sentence that states the action and the resource without waste. It earns its place and is easy for an agent to parse quickly.

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

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

For a parameterless list tool with an output schema available, the description is complete enough. An agent can safely invoke it to retrieve favorite templates without missing any critical invocation details.

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

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

The tool has zero parameters and schema coverage is naturally complete, so there is nothing for the description to add semantically. The baseline of 4 applies because no parameter documentation is needed, and the description reinforces the resource being listed.

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

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

The description uses a specific verb ('Lists') and a specific resource ('templates saved as favorites'), making the tool's purpose immediately clear. It also naturally distinguishes itself from related siblings like my_templates or search_templates by narrowing the scope to favorites.

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 identifies what the tool returns but provides no guidance on when to choose it over alternatives such as my_templates or toggle_favorite. There is no explicit context about when favorites are relevant or how this relates to other template-list sibling 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 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?

With no annotations provided, the description carries the full burden. It discloses important behavioral details: ownerWallet cannot be used to pay, payerWallet is the agent's wallet, agentWallet does not travel in the profile, accountType is 'delegate', and wallet is a deprecated alias. This goes well beyond a simple 'returns profile data' statement.

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

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

The description is information-dense but somewhat sprawling and repetitive. It front-loads the core purpose well, but the wallet explanation meanders ('Yours comes right here in payerWallet, as in my_capabilities and my_balance; agentWallet, on the other hand, does NOT travel in the profile'). Every sentence adds value, but the structure could be tightened.

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

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

For a zero-parameter read-only profile tool with an output schema, the description covers the essential decision factors: what data it returns, which sibling tools to use instead, and the critical caveat that ownerWallet cannot be used to pay. Nothing an agent needs to select or invoke this tool correctly is missing.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing to document. The description instead explains the meaning of the returned fields, which is valuable context for an agent deciding whether this tool answers its need. Baseline 4 for zero-param tools is appropriate.

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

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

The description clearly states the tool returns the owner's profile data and explicitly distinguishes it from my_capabilities and my_balance. It names the specific fields carried (email, name, handle, language, ownerWallet, payerWallet, accountType, isSeller), making the purpose unmistakable.

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

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

The description gives explicit when-to-use guidance ('the tool to pick when what you need is the data that account presents itself with') and explicit when-not-to-use guidance with named alternatives ('Do NOT use it for your scopes... that is my_capabilities. Do NOT use it for balances: that is my_balance.'). This is exemplary 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 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 burden. It discloses one behavioral trait: reviews written by agent accounts are marked with 'authorIsAgent' and shown with an 'Agent account' label. This is useful. However, it doesn't mention pagination behavior, sorting, or whether the list is read-only (though 'Lists' implies a read operation). The description adds some value but not rich behavioral context.

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

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

Two sentences, no waste. The core purpose is front-loaded, and the agent-account detail is a useful addition. It earns its place.

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

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

The tool has an output schema, so return values are covered elsewhere. The description covers the main purpose and one notable behavioral detail. However, it doesn't clarify the relationship to template_reviews (a sibling that likely lists reviews for a specific template), which could be a source of confusion. Given the tool's simplicity, this is adequate but not complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (page, pagina, rating). The description adds no parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Lists the reviews received by the builder's templates.' This clearly distinguishes it from sibling tools like template_reviews (which likely lists reviews for a specific template) and reply_to_review (which writes a reply). It doesn't explicitly name a sibling, but the scope is clear 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?

The description implies usage context: it's for viewing reviews received on the builder's own templates. It doesn't explicitly state when to use this vs template_reviews or reply_to_review, but the 'builder's templates' phrasing and the sibling names make the context reasonably clear. No explicit exclusions or alternatives 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?

No annotations are present, so the description carries the behavioral burden. It does disclose a read-only listing behavior and clarifies response semantics—each sale includes ordenId and a refund eligibility flag with a conditional motivoNo. It does not mention auth, pagination, or rate limits, but the added refundability context is genuinely useful.

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

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

Two sentences with no filler. The first sentence states the core purpose, and the second adds important response semantics. It is front-loaded and 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?

With an output schema present, the description does not need to enumerate return fields, and the optional limit parameter is fully documented in the schema. The main missing piece is usage guidance, but for a simple read-only listing tool, the description is otherwise complete enough to invoke correctly.

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

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

Schema description coverage is 100%, with both limit and the deprecated limite alias fully documented. The description adds no parameter information beyond the schema, 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 ('Lists') and a specific resource ('builder's sales'), then states the included data: state, settlement, and refund eligibility. This clearly differentiates it from siblings like my_purchases, which would cover purchases rather than sales.

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 guidance on when to use this tool versus alternatives such as my_purchases or refund_sale. The only usage signal is the phrase 'builder's sales', but there are no exclusions, prerequisites, or pointers to sibling tools.

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

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

With no annotations, the description carries the full disclosure burden, and it does so thoroughly: it explains conditional behavior (with vs without `slug`), states covered by review states, price field semantics (`regularPriceUsdc`, `discountPriceUsdc`, `priceUsdc`), rejection notes, catalog visibility, full-description behavior, and the `found: false` case. This is far more than a generic read operation statement.

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

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

The description is information-dense and every clause adds value, but it is delivered as one sprawling run-on paragraph with heavy ALL-CAPS emphasis. It is not poorly sized, but its structure hurts scannability and front-loading.

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 two optional parameters and a rich output schema, the description is remarkably complete: it explains both list and single-item modes, all review states, price semantics, rejection notes, catalog visibility, full-description handling, and the fallback behavior when the slug is not found. An agent has enough context to invoke the tool correctly without additional inferences.

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 parameters. The description still adds meaningful value by clarifying that `slug` switches the output mode, that `fullDescription` only applies to that mode, and by explaining the response shape (preview, character counts, full description). It goes beyond the schema without repeating it verbatim.

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 clear verb ('Lists') and resource ('your templates'), and precisely distinguishes two modes: list overview versus full single-template submission via `slug`. It differentiates itself from `template_details` by explicitly noting what each resolves.

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 selection guidance: use this tool to check a submission because `template_details` only resolves published templates and requires the read scope. This directly tells an agent when to choose this tool over a close sibling.

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. It discloses the on-chain nature, that the dispute only exists after the transaction is mined, that the calldata must be signed by the user's wallet, and that the owner handles evidence separately. This goes well beyond a simple side-effect note.

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 dense paragraph that front-loads the core purpose and role limitation. Each sentence adds critical process information without excess. Slightly longer than strictly necessary but well structured.

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

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

Given the tool's complexity (on-chain signing, role separation, pending state), the description is remarkably complete: it covers preconditions, action, outcome, timing, and follow-up steps. The presence of an output schema and 100% parameter coverage covers the remaining detail.

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

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

The input schema already describes all four parameters (orderId, reason, and deprecated aliases) with 100% coverage, so the description adds little beyond referencing the orderId in the calldata and the reason generally. Baseline 3 is appropriate.

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

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

The description clearly states the tool opens a dispute on an order the caller paid, creates a case with a written reason, and returns calldata for signing. This distinguishes it from dispute_status, close_expired_dispute, and withdraw_dispute, and explicitly states the buyer role limitation.

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: only the buyer (the wallet that paid) can open the dispute, and the owner/agent does not sign this calldata – evidence filing is a separate step. It also advises polling dispute_status afterwards if the read scope is present. While it doesn't name sibling tools for closing/withdrawing, the conditions for use are explicit.

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

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

With no annotations, the description carries the full burden and delivers: it discloses that status is checked both in the database and on chain, enumerates the possible statuses, explains default listing behavior, and clarifies ownership/download restrictions. It also reveals that downloads become available as soon as the deposit is confirmed, which an agent could not infer from the schema alone.

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

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

Three sentences carry the core purpose, default behavior, and ownership caveats without padding. The first sentence is somewhat dense with statuses and sources, but every sentence earns its place and the most important scoping information is front-loaded.

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

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

Even though an output schema exists and covers return structure, the description supplies sufficient operational context: how to trigger a list vs single lookup, what statuses to expect, and what the agent can and cannot do with these orders. It does not explicitly state whether the call is read-only or what happens on error, but those are minor gaps for a status tool.

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

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

Schema coverage is 100% and the schema already documents txHash, ordenId, and orderId including the deprecation. The tool description reinforces the 'without it, lists active orders' behavior but adds no new parameter-level meaning beyond what the schema provides.

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

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

The description identifies the resource (an order the agent paid) and the kind of information returned (status, next step), and it scopes the tool to 'your' orders, which helps separate it from related tools like my_purchases or dispute_status. It lacks an explicit verb such as 'returns' or 'lists', so the purpose is clear but not maximally crisp.

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 that without an orderId the tool lists the agent's active orders, and explicitly excludes owner-paid web orders, which is a clear when/when-not boundary. It does not name an alternative sibling tool to use for the excluded case, so it falls just short of the 'explicit alternatives' level.

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?

The description discloses critical behavioral traits: nobody signs in the browser, the MCP never signs nor moves funds, refunds go back to the owner's wallet, and only the owner can open or withdraw disputes. It also mentions the new-account limit [LIMITE_WALLET_NUEVA]. The dryRun parameter description adds extensive behavioral detail about what is and isn't touched during a dry run. No annotations are provided, so the description carries the full burden and does so thoroughly.

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 main description is dense but front-loaded with the most important facts (SPENDING, on behalf of owner, ready for you to pay). The parameter descriptions are long but earn their length by explaining critical safety and flow semantics. Slight redundancy between confirm and confirmar descriptions, but that's justified by the deprecation alias.

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

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

The description covers the full workflow: prerequisite (quote_purchase), the confirmation requirement, the payment mechanism (deposit_data), the refund/dispute ownership, and the dry-run testing path. An output schema exists, so return values don't need to be described. For a financial purchase-preparation tool with no annotations, this is exceptionally complete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value beyond the schema by explaining the confirm/confirmar semantics (what it does NOT do: no checkbox, no extra parameter), the quoteId's role in declaring the accepted total and the [PRECIO_CAMBIADO] rejection, and the dryRun's exact side-effect-free behavior. This goes well beyond the baseline.

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

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

The description opens with 'SPENDING: creates the purchase order ON BEHALF OF YOUR OWNER' and clearly distinguishes the tool's role: it prepares a purchase order for the owner to pay later via deposit_data, without signing or moving funds. It names the specific resource (purchase order) and the action (prepare for payment), and the contrast with quote_purchase and link_wallet helps differentiate it from siblings.

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

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

The description explicitly states the required flow: check the total with quote_purchase, then call prepare_payment with confirmar=true. It also names the alternatives (link_wallet, open_dispute, withdraw_dispute) and clarifies when they apply. The dryRun parameter description further explains when to use a dry run versus a real purchase.

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

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

With no annotations, the description carries full weight and does so well: it states no order is created, the quote reserves nothing, the discount code is not consumed, and the `quoteId` is a fingerprint of the quoted total. These are precise side-effect disclosures.

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

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

Three sentences, front-loaded with the core function, followed by workflow integration and side-effect caveats. Every sentence carries useful information with no filler.

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

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

The description covers what the tool does, what it returns, how it fits with `prepare_payment`, and its non-mutating behavior. An output schema exists, so return-value details are not required. No significant gaps 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 description coverage is 100%, so parameters are already well documented. The description adds workflow context around the discount code but does not need to repeat parameter meanings; baseline 3 is appropriate.

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

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

Description states a specific action (compute final price and breakdown) and explicit scope: it does NOT create the order. It names the returned `quoteId` and ties it to `prepare_payment`, making the tool's role unambiguous and distinct from purchase-creation 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?

Identifies the intended workflow: pass the `quoteId` to `prepare_payment` to purchase, and warns that a changed total will cause refusal rather than a mismatched order. It does not explicitly list exclusions, but the usage context is clear.

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

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

With no annotations available, the description provides extensive behavioral disclosure: it is irreversible, returns the full amount, buyer loses download, contract accepts only the seller's signature, requires sending gas, and requires a follow-up with txHash. This fully compensates for the lack of 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?

The description is dense but every sentence adds essential information. It front-loads the purpose, then gives conditional workflow branches, then constraints and consequences, with no filler. The length is justified by the number of critical behavioral details.

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

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

The description covers the full lifecycle: who signs, how gas is paid, how to confirm, when it is allowed, what happens to funds and downloads, and irreversibility. With the output schema present, no key operational detail 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?

The schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds workflow-level meaning by explaining the expected call sequence: send the sellerRefund transaction with gas, then return with { ordenId, confirmar: true, txHash }. It reinforces that confirm/confirmar must be true and that txHash is only used after the on-chain transaction.

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 precise verb and resource: a voluntary refund of one of your owner's sales. It clearly differentiates itself from dispute-related siblings by describing the refund action, escrow conditions, and irreversibility. An agent can understand exactly what this tool does.

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

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

The description explicitly distinguishes between two scenarios: when the agent collects the sale and must sign, versus when the owner collects it and handles it in My Sales. It also gives clear conditions for when refund is possible (escrow, no dispute, before deadline) and lists exclusions. This tells the agent when to use this tool and when to defer to the owner.

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 provided, the description carries the full burden of behavioral disclosure. It reveals that the operation is a text-only post, that file attachments must be handled in the browser, and that there are access restrictions (your cases, open cases, dispute-opener only). While it doesn't address side effects like notifications or irreversibility, it covers the key behavioral constraints an agent needs.

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 action and resource, then packs in all essential restrictions. Every clause earns its place, with no filler or redundant restating of the tool name.

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

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

Given the tool's simplicity, an output schema exists (so return format needn't be described), and the description covers the essential input constraints and behavioral limits. It doesn't explicitly state failure behavior for closed cases or unauthorized users, but those are directly implied by 'still open' and 'YOUR cases'. Overall, an agent has enough to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that caseId must reference a case that belongs to the user and is still open, and that text is the plain-text message content. This helps the agent understand valid parameter values without extra lookup.

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

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

The description states a specific verb and resource: 'Posts a message on one of YOUR cases'. It adds precise scoping ('still open', 'on a dispute, only whoever opened it') that clearly distinguishes this from sibling tools like reply_to_review or submit_evidence. An agent can understand exactly what action this tool performs.

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

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

The description gives clear context for when to use the tool: only on your own cases that are still open, and on disputes only by the opener. It also signals a limitation ('Text only: files are attached from the browser'), implying the tool is not for sending attachments. It does not explicitly name alternative tools for related actions, but the conditions are specific enough.

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

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

With no annotations, the description carries the behavioral burden. It does disclose a meaningful trait: the reply is 'moderated.' However, it does not mention the one-time-only nature, mutability, permissions, or what happens after moderation; those details are left to the schema and output schema.

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

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

The description is a single sentence with no filler. The key verb, resource, and moderation context are front-loaded, making it easy to parse quickly.

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

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

Combined with the fully documented schema and the presence of an output schema, the description covers the essential context: publishing, reply, review, and moderation. It does not elaborate on the moderation workflow, but for a low-complexity call the provided information is sufficient.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter semantics beyond indicating the reply text and review target; aliases, deprecation, and the character-length constraint are all already documented in the schema.

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

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

The description uses a specific verb ('Publishes') and a specific resource ('reply to a review'), making the action concrete. It is immediately distinguishable from sibling reply_to_case because the target resource is a review, not a case.

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

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

The description implies the usage context—a builder responding to a review—but does not explicitly state when to use this tool versus reply_to_case or any other alternative. It relies on the tool name and sibling list rather than giving direct routing 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 must carry behavioral weight. It says the report is sent to the team and imposes a 10-character minimum, but it does not disclose side effects, confirmation behavior, idempotency, or whether auth is required. This is thin for a mutating/reporting 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?

Single sentence with the core action front-loaded. No filler; the min-length constraint is the only extra detail and is grammatically compact.

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

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

The schema covers the four parameters and one-of requirement, and an output schema exists, so return values need not be explained. However, the description is too thin on when to select this tool and what behavior to expect beyond 'sends to team,' especially with 50+ siblings.

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 every property has a description, including deprecation notes for the aliases. The description adds no parameter meaning beyond restating the 10-character minimum already present in the schema, so it stays at the high-coverage baseline of 3.

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 action ('Reports') and target ('platform bug') plus a recipient ('to the team'). This separates it from sibling communication tools such as open_dispute or reply_to_case, even 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?

No when/why guidance is given. The description does not mention when a platform bug report is appropriate, how it differs from disputes or reviews, or any exclusions; it only states what the tool does.

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 and does so thoroughly: it discloses that the edit draft is discarded on resubmission ('discards it on resubmission'), that unchanged fields are kept, that the licence cannot be changed, and that dryRun spends no quota and touches nothing. It also contrasts dryRun against the real run, clarifying cost/side-effect boundaries.

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

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

The description is compact for the tool's complexity, front-loads the core behavior, and every sentence contributes (scope, partial updates, draft semantics, license constraint, dry run). Minor detraction: it uses a deprecated Spanish alias (`usarBorrador`) where the canonical `useDraft` would be clearer, and the structure is a single dense block rather than separated points.

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 tool with 10 parameters, nested objects, and deprecated aliases, the description covers preconditions (template yours and rejected), side effects (draft discarded, fields kept), the immutable licence, and dry-run semantics, while delegating field-level limits to a fully-described schema. It doesn't mention warranty requirements or alias strategy, but those are already exhaustively covered in the input schema, so nothing operationally critical is missing.

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

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

The input schema has 100% parameter descriptions, so the baseline applies; the main description adds only high-level guidance (send only changed fields, new ZIP optional). It also references the deprecated alias `usarBorrador` instead of the canonical `useDraft`, slightly muddying parameter selection, though the schema itself documents aliases.

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

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

The description opens with a specific verb+resource combination: 'Fixes one of YOUR templates that the review REJECTED and sends it back to the queue'. It clearly distinguishes from siblings by scoping to rejected templates and ownership, so an agent won't confuse it with submit_for_review or check_before_submit.

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 context for use (only rejected templates, only changed fields) and explains the dryRun variant for testing without side effects. However, it doesn't explicitly name sibling alternatives like submit_for_review for new submissions or check_before_submit for pre-validation, so the 'when not to use' guidance is implicit rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the irreversible nature, the effect on new sales, the requirement for user confirmation, and the outcome for prior purchasers. This is comprehensive behavioral disclosure for a destructive operation.

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

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

The description is concise and front-loaded with the key action and consequences. Every sentence adds critical information; no filler or redundancy.

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

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

For a permanent, destructive tool with 100% schema coverage and an output schema, the description covers all necessary operational details: permanence, prerequisite confirmation, and impact on existing sales. The agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents all parameters, including deprecation and aliases. The description reinforces the requirement for confirmar=true but does not add new syntax details beyond that. Baseline 3 is appropriate given the high coverage.

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

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

The description clearly states the verb (RETIRES) and the resource (your template), and specifies the consequences (leaves catalog, no new sales, permanent). It distinguishes itself from sibling tools like set_template_active by emphasizing permanence and irreversibility.

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 instructs to ask the person first before using, and mandates confirmar=true (or confirm=true). This provides clear when-to-use guidance and a critical prerequisite, which is essential for a destructive action. It also clarifies that existing buyers are unaffected.

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 is the sole source. It explains the tool can either search or return a full article by slug, and warns against inventing rules. However, it does not disclose details like pagination, result limits, or the exact structure of the response beyond 'returns the full article'.

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, well-structured sentence that front-loads the core purpose and immediate usage rule. It is concise with no wasted words, though not as terse as it could be with two 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?

Given the complexity (4 parameters, deprecated aliases, output schema present), the description provides good usage guidance but leaves out behavioral details like what happens when query vs article is used, or how results are formatted. The presence of an output schema mitigates the need to describe return values, but the tool's dual-purpose nature could be clearer.

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

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

Schema coverage is 100%, with descriptions for each parameter. The tool description adds the important distinction that query is for searching and article is for getting a full article, which complements the schema. It also clarifies the deprecated aliases in the schema, but the main description adds modest value.

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

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

The description clearly states it searches the help center and returns articles, with a specific instruction to use it before explaining platform rules. It is distinct from other search-like siblings (e.g., search_templates) by focusing on help content, though it does not explicitly name those siblings.

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 guidance to use it before explaining platform rules ('do not invent rules'), implying it should be used to ground answers in official documentation. It does not explicitly list exclusions or alternatives, but the directive is clear enough for an agent to know when to invoke 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 must convey behavior on its own. It makes the read-only, search-like nature clear, but it does not disclose ordering, match semantics, pagination behavior, or any side effects beyond what a search implies. Acceptable for a simple search operation, 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?

The description is a single, front-loaded sentence with no filler. It conveys the action, the target resource, and the main filtering dimensions without wasting words.

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

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

The detailed input schema and output schema reduce the burden on the description, and the core search behavior is clear. However, the description omits guidance on how this tool relates to sibling search and catalog tools, and it does not note the deprecated aliases except through the schema. It is minimally viable but has clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds a light summary ('text, category and platform') but does not explain edge cases, aliases, or defaults; the schema handles those, 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 states a specific verb ('Searches'), a clear resource ('the template catalog'), and the available search criteria ('text, category and platform'). It is understandable on its own, though it does not explicitly differentiate from sibling search tools like search_help or my_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 usage guidance is provided: the description does not say when to prefer this tool over alternatives, when not to use it, or whether it covers public templates versus user-owned templates. Sibling tools such as search_help and my_templates exist, so an agent gets no help choosing among them.

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.