Skip to main content
Glama

Choose products

choose_products
Read-onlyIdempotent

Displays product candidates side by side with photos so users can compare and select one for each open decision; it does not alter the cart.

Instructions

Show the user the open choices of a request side by side, with photos where the client supports it, so they pick one product for each. Use it only when the user must decide between candidates, such as two milks or 500 g against 1 kg; settle everything else yourself (favorites, usual purchases, cheapest per kg). Put all open choices of a list in one call, at most 10, each with 2 to 4 candidates and your suggestion. It changes nothing: the choices come back as a chat message, then change the cart with set_cart_item_quantity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
decisionsYesEvery open choice of the request, at most 10, shown together in one picker.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, idempotentHint), and the description reinforces it with 'It changes nothing: the choices come back as a chat message.' It adds useful behavioral detail on batching (all open choices in one call, at most 10) and the client-dependent photo support, though it does not discuss failure modes or what the returned picker contains beyond the answer.

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?

Three tight sentences, front-loaded with the purpose, then the usage boundary, then the side-effect clarification. Every clause carries information; nothing is restated boilerplate.

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?

An output schema exists and the description explains the interaction flow (returns a chat picker, then mutate via set_cart_item_quantity), the batching limits, and the decision scope. Nothing material is missing for an agent to call this 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?

Schema coverage is 100% and the nested properties are self-documenting, so the baseline is 3. The description adds value beyond the schema by explaining the batching intent ('Put all open choices of a list in one call') and framing the 2-to-4 candidate and suggestion constraint as a decision unit rather than just array bounds.

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 and resource: showing open product choices side by side so the user picks one per decision. It clearly distinguishes itself from siblings like search_products (which finds candidates) and set_cart_item_quantity (which mutates the cart).

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 when-to-use ('only when the user must decide between candidates, such as two milks or 500 g against 1 kg') and when-not ('settle everything else yourself: favorites, usual purchases, cheapest per kg'). It also names the downstream sibling set_cart_item_quantity for the actual cart change.

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