Skip to main content
Glama

Copy Basket

copy_basket

Transfer a basket from one market to another, with a per-article report showing availability, quantities, and price changes. Set replace=false to add instead of overwriting.

Instructions

Copy the basket of one market into a new basket in another market.

A market switch means building a new basket there; the per-article report shows whether the target market has each article (and in what quantity), plus price changes. The source basket is untouched. replace=True (default) empties the target basket first, so repeating the call does not double quantities; replace=False adds to what is already there.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
replaceNo
to_marketNo
from_marketNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it states the source basket is untouched, that the target is emptied when replace=True (making the call idempotent and avoiding double quantities), and that a per-article report is produced with availability, quantities, and price changes. The only gap is that it does not explain the meaning of a null from_market or an empty to_market.

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

Conciseness5/5

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

Front-loaded with the core action, then behavior, then the replace caveat. Every sentence adds information and none is redundant padding.

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

Completeness4/5

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

An output schema exists, so return values need not be spelled out, and the description covers mutation semantics and side effects well. It is slightly incomplete on the two market parameters' defaults, which matters given 0% schema coverage.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It fully explains replace (True empties, False adds) but leaves to_market and from_market semantics – including their defaults and what a null from_market implies – to inference, so only one of three parameters is meaningfully documented.

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 first sentence gives a specific verb+resource+scope: copying one market's basket into a new basket in a different market. This distinguishes it cleanly from siblings like add_to_basket, clear_basket, and view_basket without needing to open 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 Guidelines4/5

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

It frames the use case ('a market switch means building a new basket there') and clarifies the replace behavior, so an agent knows when this is appropriate. It does not explicitly name alternative tools or state when NOT to use it, so it stops short of a 5.

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