Paxaver

Create Lunch Order Draft

create_lunch_order_draft

Creates an unpaid draft lunch order with one or more items - nothing is charged until pay_lunch_order_draft commits it. Use for multi-item orders or when the user should review the total first; each items entry pairs a menu_item_id with a quantity. The draft total is the sum of item prices times quantities plus nothing else until pay_lunch_order_draft. To change or abandon the draft, use update_lunch_order_draft or discard_lunch_order_draft. FINANCIAL - confirm student, items, and date before calling.

Input Schema

Name	Required	Description
`items`	Yes	Line items to order; get IDs from get_lunch_menu. The server prices each item from the menu - a client-sent price is ignored
`menu_date`	Yes	Date the lunch is served, YYYY-MM-DD
`student_id`	No	Student ID (must be your own student; from get_my_context); required when the user has more than one student, defaults to their only student
`school_slug`	No	School slug (from get_my_context); defaults to the active school

Output Schema

Name	Required	Description
`id`	No	Draft order ID - pass to pay_lunch_order_draft
`items`	No	Draft line items
`status`	No	Order status (draft)
`menuDate`	No	Date the lunch is served, YYYY-MM-DD
`studentId`	No	Student the order is for
`schoolSlug`	No	School the order was placed at
`itemTotalCents`	No	Item total in cents - charged on finalize

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 12, 2026

changedInput schema / properties / items / description

Previous value: -"Line items to order; get IDs and prices from get_lunch_menu"New value: +"Line items to order; get IDs from get_lunch_menu. The server prices each item from the menu - a client-sent price is ignored"

removedInput schema / properties / items / items / properties / price_cents

Removed value: -{
-  "description": "Unit price in cents from get_lunch_menu",
-  "type": "integer"
-}

changedInput schema / properties / items / items / required

Previous value: -[
-  "menu_item_id",
-  "menu_item_name",
-  "price_cents",
-  "quantity"
-]New value: +[
+  "menu_item_id",
+  "menu_item_name",
+  "quantity"
+]

AddedOct 3, 2026
RemovedOct 2, 2026
AddedSep 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare it as a non-idempotent mutation; the description adds the crucial behavioral facts that nothing is charged until pay_lunch_order_draft commits, that the server prices items (client-sent price ignored), and a FINANCIAL confirm-before-calling warning. These are non-obvious traits the annotations cannot convey.

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?

Front-loads the purpose and is well organized, but 'nothing is charged until pay_lunch_order_draft' and 'plus nothing else until pay_lunch_order_draft' are somewhat redundant. Slightly dense but every sentence otherwise earns its place.

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?

With an output schema present, return values need no explanation, and the description fully covers purpose, when-to-use, sibling routing, draft/pricing behavior, and a financial-safety caution. Complete for this tool's complexity.

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 baseline is 3, but the description adds meaning beyond the schema: it clarifies that each items entry pairs a menu_item_id with a quantity and that the draft total is the sum of item prices times quantities. It restates rather than contradicts the schema's pricing note.

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 ('Creates an unpaid draft lunch order') and immediately scopes it as unpaid/draft-only. It distinguishes itself from siblings by naming pay_lunch_order_draft, update_lunch_order_draft, and discard_lunch_order_draft, so an agent can separate this from list/order/cancel tools.

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?

Gives an explicit condition for choosing this tool ('Use for multi-item orders or when the user should review the total first') and routes the agent to the right alternatives for changing or abandoning the draft. Nothing about when to use this vs the pay/update/discard siblings is left to inference.

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

All Paxaver 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?