agentPickup

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

Annotations already disclose that this is a non-destructive, non-idempotent write operation. The description adds useful behavioral context beyond that: it returns the order id and total, payment is required before the pickup QR is emailed, and the QR goes to the provided email.

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 wasted wording. Creation is front-loaded, followed by return information and the payment/email follow-up.

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

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

For a simple create-order tool with no output schema, the description supplies the key return behavior and post-payment QR delivery. It does not mention every sibling workflow, but the schema covers item sourcing from get_shop and the description covers the main post-creation flow.

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

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

Schema coverage is 67%, and the schema itself documents email, name, item id, and qty. The description adds meaning by explaining that the pickup QR is sent to the email once paid, but it does not supplement the remaining parameter details beyond what the schema already provides.

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

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

The description states a specific verb and resource: create a pickup order to collect in person. It also distinguishes the follow-up action by naming pay_order, so an agent can separate creation from payment.

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 usage context: create an order for in-person collection, then pay it with pay_order. It does not explicitly say when not to use it or compare it to all siblings, but the workflow context is sufficient for 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?

Annotations already declare readOnlyHint and openWorldHint, so the description's main added value is the authentication requirement (Sign-In-With-X) and the ownership constraint that the order must be one this wallet paid. Those are exactly the non-obvious behavioral facts an agent needs before calling. It stops short of describing failure modes for unauthenticated or unpaid orders.

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 clause listing the returned artifacts, followed by the auth and ownership qualifier. No filler; the only weakness is the sentence-fragment style, which makes the action verb implicit.

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 read tool with no output schema, the description covers what comes back and the auth model, which is the core need. It leaves gaps on the order_id source and on error behavior when the order was not paid by the caller's wallet.

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 0% for the single parameter, and the description never names or describes order_id directly; it only implies 'an order this wallet paid'. The ownership constraint adds real meaning beyond the bare string type, but format and source of the ID remain undocumented.

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

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

The description names a specific deliverable (pass link, pickup code, QR content) for a specific resource (an order paid by this wallet), which is far more informative than the title's restatement. It does not distinguish itself from siblings like order_status, but the retrieved artifacts are distinct enough that an agent can identify the purpose.

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

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

Usage is implied through the precondition that the order must have been paid by this wallet, which effectively tells the agent when this tool is applicable. However, there is no explicit statement of when to choose this over order_status or create_pickup_order, and no mention of what happens for unpaid orders.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine value beyond them by disclosing the return content (item ids, prices, pickup location, payment methods), which matters because there is no output schema. It does not say whether the result is a single shop or a list, which is the one material ambiguity.

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 compact sentence that packs four distinct pieces of return information with no filler. Front-loaded with the primary payload (what the shop sells) before secondary 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?

With no output schema, the description carries the burden of describing returns, and it does so across items, prices, pickup location, and payments. The gap is not stating the cardinality or format of the response (single shop vs. list), which leaves a small hole an agent must discover by calling.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a context-free call, though it does not explicitly confirm that no shop identifier is required — the most likely source of agent confusion for a tool whose result could plausibly depend on a shop.

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 the resource and enumerates what it exposes: item ids, prices, collection point, and accepted payments. That is specific enough for an agent to know this is a shop-catalog read. It stops short of differentiating itself from the ordering siblings (create_pickup_order, pay_order), leaving the agent to infer that this is the discovery step.

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 when-to-use statement and no named alternative. The implied flow is clear from the sibling set — call this before ordering to learn what is available, where to collect, and how to pay — but that sequencing is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description's real contribution is the status vocabulary (waiting for payment, paid, ready to collect, collected, expired), which helps an agent interpret results in the absence of an output schema. It says nothing about not-found orders, invalid IDs, or error behavior, which matters for an open-world lookup.

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 short and free of padding, but it is a bare fragment with no leading verb, so the core action is not front-loaded. A single added clause such as 'Returns the status of an order' would fix both structure and purpose at almost no length cost.

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 no output schema, the description carries the burden of explaining what comes back; it partially does so via the state list but never frames it as a return value. For a read-only lookup taking an order_id, it should at minimum state the input's meaning and the not-found case.

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

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

Schema description coverage is 0% and the single required order_id parameter is undocumented in both schema and description. The description never mentions what an order_id is, where it comes from, or its format, so it fails to compensate for the coverage gap.

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 enumerates the possible order states but never states the verb or that it returns a status for a given order_id – it reads as a sentence fragment. An agent can infer a status lookup from the name and title, but the text itself never says what it does. It also does nothing to distinguish it from pay_order or get_pickup_pass, which touch the same order lifecycle.

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

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

There is no when-to-use guidance, no preconditions, and no mention of the siblings (pay_order, create_pickup_order, get_pickup_pass) that an agent would need to choose between. The state list hints at polling use cases but never says so explicitly.

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 annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description's highest-value additions are the real-money warning, the exact funding wallet, and the payment rail (x402). It also discloses the main return artifact ('the pickup pass link'), which goes beyond the annotations. What it omits is failure/refund behavior and whether the payment is escrowed or immediately settled.

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 short sentences, front-loaded with what it does, then the safety gate, then the return value. Every clause earns its place; nothing is redundant with the title or schema.

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

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

For a spend-money mutation with a single parameter, the description covers the key pieces: mechanism, funding source, user-confirmation prerequisite, and the return value (no output schema exists, so naming the pickup pass link matters). The remaining gap is post-call behavior — what the agent should report on failure or duplicate submission — but that is a modest omission for an idempotent, single-param tool.

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

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

Schema description coverage is 0% for the single required parameter, so the description must carry the meaning — and it never explains that order_id comes from create_pickup_order or what format it takes. The implicit link between 'Pay an order' and an order identifier is enough for an agent to guess, but not enough to be confident about sourcing the 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 opens with a specific verb and resource ('Pay an order') plus the mechanism ('in USDC over x402') and the funding wallet, so an agent knows exactly what the tool does. It stops short of naming how it relates to siblings like create_pickup_order or order_status, but the payment verb is distinct enough from the get/list tools that confusion is unlikely.

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

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

It states a clear precondition for use: 'This spends money: confirm the items and total with the user first,' which tells the agent when this is appropriate and what gate must pass before calling. It does not explicitly route to create_pickup_order as the prerequisite step or say what to do if payment fails, so the ordering of the workflow is implied rather than stated.

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