Café QR

Mark an item sold out or back on

set_item_sold_out

Idempotent

Mark one menu item sold out (guests stop seeing it on the QR menu, the till greys it out) or back on, at one branch or all of them. Confirm the item and branch with the person before calling. Easy to undo by calling again with soldOut false.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "item": "<item>",
      "soldOut": "<soldOut>"
    },
    "name": "set_item_sold_out"
  }
}

Input Schema

Name	Required	Description
`cafe`	No	Which café, by name or slug. Only needed when the person has more than one (see list_my_cafes).
`item`	Yes	The item's name (or id from search_menu).
`branch`	No	One branch (location) by name or id. Leave out for the whole business.
`soldOut`	Yes	true = sold out, false = back on.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, so the bar is lower, yet the description still adds real value: it explains the guest-visible and till-visible effect of the change and that it is 'easy to undo by calling again with soldOut false'. It does not discuss permissions or what happens if the item/branch is ambiguous, which keeps it short of a 5.

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 short sentences, front-loaded with what the tool does and its visible effect, followed by the confirmation rule and the undo path. Every sentence carries distinct information; nothing is repeated from the schema or annotations.

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?

For a four-parameter mutation with no output schema, the description covers purpose, effect, scope, human confirmation, and reversibility – enough to call it correctly. Minor gaps remain around what happens on ambiguous item names or insufficient permissions, but nothing essential is missing.

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 description coverage is 100%, so item, café, branch and soldOut are all documented in the schema itself, including the soldOut true/false meaning. The description only echoes scope ('one branch or all of them') without adding syntax or format detail, so the baseline 3 applies.

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 ('Mark one menu item sold out ... or back on') plus the scope ('at one branch or all of them'), and even describes the observable outcome (guests stop seeing it on the QR menu, till greys it out). An agent can distinguish this from the read-only siblings like search_menu or get_live_status immediately.

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?

Gives a clear precondition – 'Confirm the item and branch with the person before calling' – and specifies the scope choice between one branch and all of them. It does not name a sibling alternative for locating the item (search_menu is only referenced in the schema), so routing guidance is implied rather than explicit.

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

All Café QR 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?