Skip to main content
Glama

RoboTrunk

Check one product before buying it

check_product
Idempotent

Answers one question about one product: send its name, barcode, any product page link or a RoboTrunk reference. Returns the checked facts with a source for each, the live recall status, every store selling the same variant with the cheapest not sold out, and the exact create_checkout arguments; with a country, landed_cost adds price_plus_delivery (not a total). It helps before recommending or buying a product, wherever it is sold: on any product the person is weighing, it adds the live recall check, the checked facts and the price new to what you already know. For a second-hand listing they have in front of them, use check_listing, which runs this check on the listing's text. Not for browsing; use search_catalog. Use resource.recall.status as the recall headline. For lookup_pending, wait about 60 seconds and use its exact-input check_product action once; for identification_pending, wait about 15 seconds and use that action once. If it remains pending or incomplete, stop automatic retries. A found result stays the headline; listings_read[] is historical and does not override it. lookup_incomplete and lookup_skipped have no retry action; recall_lookup_incomplete means the live lookup ended without a complete result. none_found_after_lookup is not a safety guarantee. Next: create_checkout with resource.next_step.arguments (choose a variant or offer first when next_step says so); the answer also lifts that step to next_actions and suggested_tools. Error recovery: invalid_request names the field to fix; not_identified means ask the person for the product's page link or its brand and model, then call again (gtin_not_known: send a store link instead of the barcode); ambiguous means show the person the candidates and call again with the one they choose; not_found or not_indexed means call again with the product's name; unavailable means an unlisted check may be tried once later with the same inputs; if it remains unavailable, stop automatic retries and tell the person the check did not run. A candidate's reference or a link on a store RoboTrunk offers needs no model; rate_limited means wait the seconds it names; check_failed means retry once, then use search_catalog and get_product; checked_not_listed is not a failure: relay the recall result and say RoboTrunk does not sell it; any other error, including tool_layer_failure: retry once, then call submit_feedback. Full guide: get_tool_guide or /agent/tools.json#check_product Example call: {"product":"Nuna PIPA urbn infant car seat","buyer_country":"US"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoISO country code the person has said the item is going to, so the cheapest offer from a store shipping there is chosen. Null if not said; never guess.
productYesThe product's name in the person's words, its barcode, any product page link, or a RoboTrunk reference. One product.
postcodeNoWith buyer_country or country: postcode the person has said, used only to price shipping and never stored. Null when not said; never guess.
buyer_countryNoShopper's ISO country: what you know, else your best guess; unknown if none. Left out, it is read as unknown and the answer asks you to send it. Example: "AU", "US" or "unknown", never a country name.unknown
buyer_country_basisNoOptional, with buyer_country: known if you know the country, guessed if it is your best guess. Null if neither.
shopping_session_idNoOptional server-issued shopping session correlation ID. It is not purchase authority.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Far exceeds what annotations provide: pending-state timeouts (60s lookup_pending, 15s identification_pending), retry stop conditions, rate-limit handling, the fact that postcode is never stored, recall-result precedence over listings_read[], and the caveat that none_found_after_lookup is not a safety guarantee. Nothing here contradicts readOnlyHint=false / idempotentHint=true.

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

Conciseness3/5

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

Purpose, siblings and next steps are front-loaded, but the body is a very long error-code catalog (invalid_request, not_identified, ambiguous, not_found, not_indexed, unavailable, rate_limited, check_failed, checked_not_listed, tool_layer_failure) that largely duplicates the referenced full guide. It is dense but not wasteful in intent, so it lands at a middling score rather than failing.

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

Completeness5/5

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

No output schema exists, and the description compensates by describing returns (checked facts with sources, live recall status, sellers with cheapest in-stock, exact create_checkout arguments) plus full recovery behavior. An agent has everything needed to call and interpret it.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description still adds interpretation beyond the schema, notably that a supplied country makes landed_cost add price_plus_delivery rather than a total, and that a candidate reference or store link needs no model. It does not add new syntax for the remaining params.

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

Purpose5/5

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

States a specific verb+resource+scope: 'Answers one question about one product', with the accepted input forms enumerated. It explicitly distinguishes itself from check_listing and search_catalog, so an agent can route correctly 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.

Usage Guidelines5/5

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

Gives explicit when-to-use ('before recommending or buying a product, wherever it is sold') and when-not ('Not for browsing; use search_catalog'; second-hand listings go to check_listing). Alternatives are named with the condition that selects them.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources