Skip to main content
Glama

RoboTrunk

Watch a purchase's products for a recall

watch_recalls
Idempotent

Starts a post-purchase recall watch on every product in a checkout that has been handed to the store to pay, once the person (or an agent authorised to accept on their behalf) has agreed to the current consent statement. RoboTrunk re-checks each watched product whenever a regulator publishes a new notice naming its brand; a match only ever flags with the regulator's own citation and never changes, cancels or delays the purchase. An item not matched to a listed product is watched by its checkout name, not refused; each product says watched_by "product" or "name". The full consent statement, version recall-watch-consent-v1: "RoboTrunk will watch the products in this purchase for a recall. What is watched: each product bought through this checkout hand-off, re-checked whenever a regulator publishes a new notice naming its brand. What is stored: the product and its title, the channel chosen to be told (poll, an agent callback URL, or a person's email address), and, only for a channel that is switched on, that URL or address; never a name, a postal address or payment details. Channels: an agent can always poll get_recall_watch for the result; a callback URL is used only when RoboTrunk has switched callbacks on; a person's email is used only when RoboTrunk has switched email on, the person consents under the Australian Spam Act, and the address holder confirms it by a link sent to that address. Frequency cap: at most three messages a day on one channel, and at most one email a day to one address, several alerts combined into one. How to stop: call stop_recall_watch at any time, or use the one-click stop link in an email; stopping is instant and permanent, and removes the stored channel data. This watch never changes, cancels, blocks or delays the purchase it watches; a recall only ever flags with its regulator citation." channels is optional: leave it out for the poll-only watch every purchase gets, and a channels value that cannot be read is left out the same way, with the answer saying poll was used. One watch per checkout: a second call returns the existing watch unchanged, and a stopped watch cannot be restarted. Use it after complete_checkout; keep the watch_token it returns (shown once) for get_recall_watch and stop_recall_watch. Error recovery: consent_required means show the person the statement above and call again with it; invalid_request names the field to fix; channel_not_available means retry with channels left out (poll only); checkout_not_handed_off means call complete_checkout first; checkout_ended means there is nothing to watch; watch_stopped means this checkout's watch was stopped and cannot restart; product_not_resolved means no item could be matched or named; use check_product; checkout_too_large means more than 50 different products; forbidden, not_found or checkout_not_found means that checkout cannot be read here, so send checkout_id exactly as an earlier answer returned it; continuation_not_found means that reference is unknown or expired, so call create_checkout again; rate_limited means wait and retry; service_unavailable means try again later; watch_failed (or any other unexpected error): retry once, then call submit_feedback. Next: get_recall_watch to poll for alerts. Full guide: get_tool_guide or /agent/tools.json#watch_recalls Example call: {"checkout_id":"mcp1_c_examplereferencevaluehere0000000000000","consent":{"given_by":"person","statement_version":"recall-watch-consent-v1"},"channels":[{"kind":"poll"}]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
consentYes
channelsNoOptional: leave it out for a poll-only watch (poll is always on); a value that cannot be read as this list is left out and the answer says poll was used. When sent, one or more channels: callback and email are refused channel_not_available until RoboTrunk switches them on. Example: [{"kind": "poll"}].
checkout_idYesThe reference get_checkout accepts for this checkout.
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?

Annotations cover the safety profile (idempotentHint=true, destructiveHint=false), and the description adds far more: exactly what data is stored, the 3-message/1-email daily cap, that the watch never alters the purchase, the one-watch-per-checkout behavior, and that a stopped watch cannot be restarted. The stated idempotency ('a second call returns the existing watch unchanged') is consistent with the annotations.

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?

The purpose and preconditions are front-loaded, which is good, but the description is extremely long and embeds the entire consent statement verbatim even though it is also available via get_tool_guide, creating substantial bloat. The exhaustive error enumeration, while useful, compounds the length beyond what a tool description needs.

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?

With no output schema, the description still tells the agent that a watch_token is returned (shown once) and how to use it, plus full consent and error handling. For a complex, consent-gated, idempotent mutation tool, every piece an agent needs to call it correctly is present.

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 75%, and the description compensates well: it explains that channels is optional and defaults to poll-only, describes the three channel kinds and their activation conditions, and emphasizes the exact statement_version requirement. It adds real meaning beyond the schema, though shopping_session_id is not addressed in prose.

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?

The opening sentence states a specific verb and resource ('Starts a post-purchase recall watch on every product in a checkout'), and it clearly separates itself from siblings by naming get_recall_watch (poll) and stop_recall_watch (stop). An agent can distinguish this from watch_back_in_stock without opening any schema.

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

Usage Guidelines5/5

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

Explicit preconditions ('Use it after complete_checkout', checkout must be handed off, consent required), explicit next steps (get_recall_watch to poll), and a full error-recovery table that maps every error code to the corrective action. When-to-use and when-not-to-use are both covered.

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