Skip to main content
Glama
CydVilla

Peckish

by CydVilla
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

add_doubledash_item

Add one selected menu item from an offered store to an existing delivery cart or placed order, returning a cart_id for preview and user-approved submission.

Instructions

Add ONE item from an offered store to an existing delivery. Returns a cart_id — then preview_order it as cart_uuid, show the user the summary, and submit only on their go-ahead. If the response has link_confirmed false the item did NOT attach: do not preview, do not submit, and do not add it again — tell the user. Needs dd-cli >= 0.2.6.

Input Schema

NameRequiredDescriptionDefault
queryNoThe query passed to search_doubledash, when the item came from that search. Placed orders only — not allowed with cart_uuid
intentYesOne short line stating who this is for and the goal, e.g. 'Help the user order dinner'. DO NOT include the user's verbatim words, dietary/health/religious details, budgets, names, or other personal specifics — a generic goal is expected.
item_idYesitems[].item_id from that store
menu_idNoitems[].menu_id from the same item; omit only when it had none
quantityNoHow many, 1-20 (default 1)
store_idYesstores[].store_id from list_doubledash_options or search_doubledash
cart_uuidNoAn unsubmitted delivery cart — this or order_uuid
order_uuidNoA placed order's UUID — this or cart_uuid
nested_optionsNoJSON array of chosen options when the item has requires_options true, e.g. '[{"id":"<group_id>","options":[{"id":"<option_id>","quantity":1}]}]'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover openWorldHint and safety hints, and the description goes beyond them: it declares the return shape (cart_id, link_confirmed), explains the failure semantics of a non-confirmed link, and pins a minimum client version (dd-cli >= 0.2.6). These are the exact operational facts an agent needs for a network-mutating add.

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?

Purpose is front-loaded in the first clause, followed by the happy-path flow, the failure branch, and finally the version requirement. Every sentence carries actionable content; nothing is redundant or padded.

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 9-parameter, no-output-schema mutation tool, the description supplies what the structured fields cannot: return shape, success/failure branching, downstream call sequencing, and a client-version gate. Nothing an agent needs to invoke it safely appears to be missing.

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%, so the schema carries the per-parameter burden and baseline is 3. The description adds real cross-parameter meaning the schema does not: the returned cart_id must be passed back as cart_uuid, linking the output of this call to the input of the next.

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 (Add), resource (item), quantifier scope ('ONE'), and target ('an existing delivery'), which alone distinguishes it from the bulk-oriented sibling add_items_to_cart. An agent can identify the operation without opening the 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?

Explicitly sequences the tool after invocation: preview_order with the returned cart_id as cart_uuid, show the summary, submit only on the user's go-ahead. It also names a hard stop condition ('link_confirmed false') with concrete prohibitions: do not preview, do not submit, do not add again, tell the user.

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

Deploy Server

Other Tools