teas.co.uk

Buy again

reorder

Use this when a signed in customer wants to buy again from an earlier teas.co.uk order. order_number comes from my_orders, and only orders on the linked account are found. only_ids limits it to those product ids from that order; otherwise every product is added in its original quantity. Products are added to the basket at today's prices, on top of anything already there. Products that cannot be added now (no longer sold, out of stock, or over the 20 kg parcel limit) are listed in messages and skipped. If nothing from the order can be found it returns an error. Calling it again adds the products again. Nothing is bought or charged until the customer pays on teas.co.uk.

Input Schema

Name	Required	Description
`only_ids`	No	Optional: only these product ids from that order.
`order_number`	Yes	The earlier order number.
`idempotency_key`	No	Optional. A unique key for this change (8 to 128 letters, digits or . _ : -). Sending the same key again within 24 hours returns the first answer instead of making the change twice.

Output Schema

Name	Required	Description
`added`	No
`items`	Yes	Number of items in the basket.
`lines`	Yes
`delivery`	Yes
`messages`	Yes	Anything that could not be added or changed, in plain words.
`subtotal`	No	Pounds including VAT, before delivery.
`basket_id`	No	Present only when the host did not identify the user: pass it to later basket tools.
`from_order`	No
`subtotal_text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

addedInput schema / properties / idempotency_key

Added value: +{
+  "description": "Optional. A unique key for this change (8 to 128 letters, digits or . _ : -). Sending the same key again within 24 hours returns the first answer instead of making the change twice.",
+  "maxLength": 128,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9._:-]{8,128}$",
+  "type": "string"
+}

First observedOct 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses rich behavior beyond the annotations: today's prices, stacking on the existing basket, skipping unbuyable items (discontinued, out of stock, over 20 kg) into messages, error when nothing is found, repeat-call accumulation, and that nothing is charged until payment. This is exactly the mutation context the sparse annotations (destructiveHint=false, idempotentHint=false) do not provide.

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

Conciseness4/5

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

It is long but dense and front-loaded with the use case, and nearly every clause carries behavioral or routing information. Minor repetition of 'added' wording keeps it just short of maximally tight.

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?

For a basket-mutating tool with an output schema, it covers the failure modes, skip-and-report behavior, pricing semantics, and no-charge guarantee. An agent has everything needed to call it correctly.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: order_number originates from my_orders and only linked-account orders resolve, while only_ids restricts to specified product ids from that order and otherwise every product is added at original quantity.

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?

It states a specific verb and resource ('buy again from an earlier teas.co.uk order') and clarifies the operation's scope. An agent can distinguish it from add_to_basket or view_basket without further reading.

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

Usage Guidelines4/5

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

It gives an explicit trigger ('when a signed in customer wants to buy again') and routes the agent to my_orders for the order_number. It lacks explicit when-not-to-use or named alternatives for non-order additions, but the context is clear.

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

All teas.co.uk tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?