Stamped MCP by usefulapi

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety behavior is covered. The description adds useful API context (V3 API, GET endpoint), but does not describe authentication requirements, error behavior, or response characteristics.

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-loaded with the core operation. Every clause contributes: record scope, id source, API version, and endpoint. No wasted text.

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 one-parameter read tool with read-only annotations and no output schema, the description is largely sufficient. The only meaningful gap is that it does not clarify the return shape or differentiate from stamped_lookup_customer.

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 single customer_id parameter is already documented. The description adds only that the id comes from stamped_list_customers, with no additional format or validation details beyond the schema baseline.

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

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

States a specific verb and resource: retrieve one customer record by Stamped customer id. It also identifies where the id comes from (stamped_list_customers), which distinguishes it from the list tool. However, it does not distinguish itself from the sibling stamped_lookup_customer.

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 parenthetical 'customerId from stamped_list_customers' implies the typical usage flow after listing customers. There is no explicit guidance on when to use this tool versus stamped_lookup_customer, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the API version (V3) and the underlying REST endpoint, which is mild context but says nothing about not-found behavior, error shape, or what the response contains.

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 fragments, purpose front-loaded, zero padding. Minor deductions: the raw endpoint path is low-value for an agent, and the camelCase 'orderId' does not match the schema's 'order_id', a small risk of confusion.

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?

A single-parameter read tool with full schema coverage, no output schema, and annotations carrying the safety profile. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already documents order_id as 'Stamped order id.' The description's contribution is only the provenance hint (source it from stamped_list_orders), which is a small addition beyond the schema — consistent with the baseline 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 specific verb and resource ('One order by Stamped order id') and names the sibling that supplies the id (stamped_list_orders). It does not, however, distinguish itself from stamped_lookup_order, which appears to retrieve the same object by a different key — a meaningful ambiguity 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 parenthetical 'orderId from stamped_list_orders' gives useful provenance for the required input, implying the intended workflow (list then get). But there is no explicit when-to-use/when-not guidance and no mention of when stamped_lookup_order would be preferred.

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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful API context (V3 endpoint) but does not describe auth, rate limits, or return 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 front-loaded, dense, and free of filler. It states the core operation, id source, API version, and endpoint in very little space.

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 one-parameter read tool with annotations covering safety, the description provides enough context to invoke it correctly. It does not explain the return shape, but that is a minor gap for a straightforward product getter.

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 product_id parameter is already documented. The description adds provenance value by specifying that productId comes from stamped_list_products, going slightly 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 it retrieves one product by Stamped product id, and it names stamped_list_products as the source of the id. It does not distinguish itself from the sibling stamped_lookup_product, so sibling differentiation is incomplete.

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 clear usage context by saying the productId comes from stamped_list_products, which helps the agent know when this tool applies. It does not explicitly address when to use stamped_lookup_product instead, so exclusions are missing.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's added value is what data actually comes back (addresses and a loyalty activity summary with points and VIP tier) plus the V3 dashboard prerequisite. There is no output schema, so this return-content disclosure matters more here; absence of pagination and rate-limit commentary is a minor gap covered partly by the schema's page/limit docs.

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 compact clauses, front-loaded with the action and resource, then the optionality note, then the API version/endpoint. The parenthetical field list is dense but every item earns its place by telling the agent what the records contain.

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 17-parameter, all-optional list tool with no output schema, the description supplies the essentials: what comes back, that no filter is required, and the platform precondition. It lacks guidance on result ordering or filter combination behavior, which an agent forming complex queries might want.

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

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

Schema coverage is 100%, so all 17 parameters are already documented with types, bounds and meaning. The description adds only the meta-statement that every filter is optional and hints at filterable dimensions (email, name, tags, loyalty), which is baseline-level value over the schema, not new syntax or semantics.

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 gives a specific verb+resource ('Filter and list customer records') and enumerates the record shape (email, name, tags, addresses, loyalty points/VIP tier), which is more than a restatement of the title. It does not explicitly distinguish itself from siblings like stamped_get_customer or stamped_lookup_customer, leaving the agent to infer list-vs-single from the name alone.

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

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

'All filters are optional' tells the agent it can call with no arguments to enumerate everything, and the 'only for shops on the Stamped Loyalty 2.0 dashboard' constraint is a genuine eligibility gate that prevents wasted calls. However, no alternative tool is named for single-customer retrieval or for non-2.0 shops, so the when-not path is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so "no points are changed" largely restates structured data. The description does add useful context — that this is an audit-oriented ledger view and that it targets the V3 / Loyalty 2.0 API — but says nothing about volume, rate limits, or result ordering.

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

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

Front-loaded with the report's identity and contents, then the read-only caveat, then the API path. The parenthetical field list is dense but each item is informative; only the trailing endpoint string is arguably filler.

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

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

With no output schema, the description usefully enumerates the payload contents (rule, points, event, order id/breakdown, customer id), which is exactly what an agent needs to decide whether to call it. Pagination is covered by the schema, so its absence from the description is not a real 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%: both `page` and `limit` are documented in the schema, including the more_pages/next_page guidance and the 1-100 range. The description adds no parameter detail, so baseline 3 applies.

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

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

States a specific verb (list/report) and resource (loyalty activities = points ledger) and enumerates the fields returned (rule, points credited/debited, event, order id, customer id). It is clearly distinct from stamped_get_customer or stamped_list_orders, though it never explicitly contrasts itself with the closest sibling, stamped_list_loyalty_rewards.

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?

"Read-only audit view" implies the use case (auditing the points ledger), but there is no explicit when-to-use/when-not or routing to alternatives such as stamped_list_loyalty_rewards for the reward catalog. Usage must be inferred from the field list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds meaningful context beyond that: coupon codes are masked with specific rules, coupon_code_masked is returned, nothing is redeemed or voided, and it is a V3 Loyalty 2.0 endpoint. It does not mention rate limits or pagination behavior, which keeps it from a 5.

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

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

The purpose is front-loaded and the extra sentences are short and useful. The long parenthetical listing fields and masking rules is dense but each detail earns its place for a report tool without an output 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?

With no output schema, the description compensates by listing the returned fields and explaining the masking behavior of coupon codes. Combined with the read-only audit framing and the schema's pagination documentation, an agent has what it needs 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 description coverage is 100%, so both page and limit are already fully documented in the schema. The description adds no parameter-level detail, 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 and resource: a loyalty rewards report listing rewards customers earned or redeemed, with enumerated return fields. It clearly distinguishes rewards from generic customer/order/product tools, but does not explicitly differentiate itself from the sibling stamped_list_loyalty_activities.

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 by 'Loyalty program report' and 'Read-only audit view,' but there is no explicit when-to-use guidance, no when-not-to-use exclusions, and no named alternative such as stamped_list_loyalty_activities for activity-level data.

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 cover the safety profile (readOnly, non-destructive, openWorld), and the description adds genuinely new behavioral facts: results are paged, no filter parameters are supported server-side, and the call maps to GET /api/v3/merchant/shops/{shopId}/orders on V3. It doesn't discuss rate limits or result-size bounds, so it falls just short of full disclosure.

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

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

Three short sentences: what it returns, how pagination/alternatives work, then endpoint metadata. Return contents come first, the alternative is signposted mid-stream, and nothing is redundant.

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 usefully enumerates the return fields an agent can expect and flags the paged envelope with more_pages/next_page. Missing only auth/scope requirements and any note on default page size, which keeps it from a 5.

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

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

Schema description coverage is 100% — page is documented as zero-based with min/max and limit as 1-100 — so the schema already carries the semantics. The description's "Paged" adds only a nudge toward the pagination fields, which is baseline-appropriate rather than value-adding.

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

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

States a specific verb (list) and resource (order records) and enumerates what an order record contains: customer id, currency, line items, cart states, discounts, dates. It also names the single-order sibling so an agent can separate this from a lookup without opening either schema.

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

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

Explicitly warns that Stamped documents no filters for this list and routes single-order retrieval to stamped_lookup_order, which prevents a wasted filtered-query attempt. It stops short of covering the other retrieval siblings (stamped_get_order, stamped_lookup_customer), so it is clear but not exhaustive.

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, destructiveHint=false and openWorldHint=true, so safety is covered without the description's help. The description adds the API version and concrete endpoint, but omits return shape, default page size, and whether filters combine with AND or OR — meaningful behavior for an open-world list 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?

Three short sentences, front-loaded with the purpose and filterable fields, then the optionality constraint and endpoint. 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 12-parameter read list tool with no output schema, the description covers the filter surface but leaves pagination mechanics and filter-combination semantics to the schema. Annotations carry the safety profile, so the remaining gap is moderate rather than severe.

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?

With schema description coverage at 100%, the schema already documents all 12 parameters including page, limit and the platform-id filters. The description only restates a subset (title, vendor, type, handle, status, tags) and adds no semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Filter and list the product catalog Stamped holds') and enumerates the filterable fields, so the agent knows exactly what is returned. It does not name a sibling such as stamped_lookup_product or stamped_get_product, so differentiation relies on the agent inferring list-vs-single from the 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?

'All filters are optional' is the only usage signal, and it clarifies that an unfiltered call is valid. There is no guidance on when to prefer this over stamped_lookup_product or stamped_get_product, and no mention of pagination workflow despite paging being a core concern for a 12-parameter list tool.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds the API version and endpoint path, but does not disclose auth requirements, not-found behavior, or rate limits.

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

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

The description is short, front-loaded, and every element earns its place: the lookup target, the exactly-one constraint, the API version, and the endpoint.

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?

It is sufficient to invoke the tool for a read-only lookup, especially given annotations and rich schema descriptions. However, it omits not-found behavior and does not clarify how the shopId in the endpoint path is supplied relative to the schema parameters.

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 the important cross-parameter constraint that exactly one of email or a platform id must be supplied. That cardinality rule is not expressed in the schema itself.

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

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

The description states a specific action and resource: find one customer by email or a platform id. It distinguishes lookup from list-style siblings by emphasizing a single customer, though it does not explicitly differentiate itself from stamped_get_customer.

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 clear context for use: lookup a single customer via email or one platform identifier, and requires exactly one identifier. It does not name when to use stamped_get_customer or stamped_list_customers instead.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the API version and endpoint path, which is modest extra context, but says nothing about what happens on a miss or on multiple ids being supplied.

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

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

Two compact clauses plus the endpoint, with the identifier constraint front-loaded. The raw HTTP path is somewhat developer-facing but does reinforce the openWorld hint; nothing is wasted.

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

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

For a three-way identifier lookup with no output schema, the description should say what comes back (a full order object vs. a stub) and what a no-match looks like. Those are the remaining gaps; the input side is fully covered.

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 each of shopify_id / bigcommerce_id / custom_order_id is already documented. The description nevertheless adds a genuine constraint absent from the schema: exactly one identifier must be provided (the schema enforces no such mutual exclusion, and required parameters = 0).

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

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

States a specific verb and resource — 'Find one order by a platform order id' — plus the concrete endpoint (GET /api/v3/merchant/shops/{shopId}/orders/lookup). It never contrasts itself with the sibling stamped_get_order, so the agent must infer that lookup is by external platform id while get is presumably by internal id.

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?

'give exactly one' conveys the key invocation constraint (mutually exclusive identifier choice), but there is no guidance on when to prefer this over stamped_get_order or stamped_list_orders, and no note about error behavior when no order matches.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the V3 endpoint path, which is redundant with the read-only hint, and says nothing about behavior when an id matches nothing or when the API returns a non-200.

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

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

Two short sentences with the operational constraint front-loaded ahead of the endpoint detail. The trailing 'V3 API. GET /api/v3/...' is largely redundant with the annotations and is the one part that does not clearly earn its place.

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

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

For a simple read-only lookup with a fully documented three-field schema, no output schema, and annotations covering safety and openness, the description supplies what an agent needs to call it. Returned product fields and not-found behavior are unstated but are minor given the tool's low complexity.

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 a real constraint the schema cannot express: all three id parameters are optional and unconstrained by any oneOf, yet the description states exactly one must be supplied. That is genuine semantic value beyond the schema.

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

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

States a specific verb and resource: find one product by a platform id. It implicitly distinguishes a keyed lookup from the sibling list_products and get_product, though it never names those siblings explicitly, so differentiation is left partly to inference.

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 parenthetical 'give exactly one' gives a usable calling constraint, but there is no statement of when to prefer this over stamped_get_product, stamped_lookup_order-style siblings, or stamped_list_products. Usage is implied rather than routed.

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