Skip to main content
Glama
Sign In
edhec-mcp

edhec-mcp

by Sillvs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Prepare a snack-corner order

resto_order_prepare

Builds an unpaid snack-corner cart from selected main and sides and returns itemized totals, discounts, balance, pickup place, and a 10-minute confirmation ID before booking or payment.

Instructions

Step 1 of 2 (beta). Builds an UNPAID cart for one snack-corner formula and returns the exact summary: items, total, discounts, balance before/after, pickup place, plus a confirmationId (valid 10 minutes). Nothing is booked or paid. Only call this when the user asked to order food and named the items (or clearly agreed to your suggestion). Product names can be partial ("thon mayo", "gaufre choco") or ids from resto_order_offer. Then show the summary to the user and wait for an explicit yes before resto_order_confirm.

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": {
      "main": "<main>",
      "sides": "<sides>"
    },
    "name": "resto_order_prepare"
  }
}

Input Schema

NameRequiredDescriptionDefault
mainYesThe main item (sandwich, pasta, ciabatta ...)
sidesYesThe side items in order, e.g. ["yaourt", "gaufre liegeoise chocolat"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations it discloses the crucial semantics: nothing is booked or paid, the cart is unpaid, and the confirmationId expires after 10 minutes. It also imposes a human-in-the-loop requirement, which an agent could not infer from readOnlyHint=false and destructiveHint=false alone.

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 step-and-status, then behavior, then call condition, then next step — a logical order with no filler sentences. Every clause carries operational information.

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?

There is no output schema, so the description enumerates the return payload (items, total, discounts, balance before/after, pickup place, confirmationId) itself. For a two-parameter ordering tool with a required confirm step, the description covers everything an agent needs to invoke and continue 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%, so the two parameters are already documented. The description still adds meaning by saying product names may be partial strings ('thon mayo', 'gaufre choco') or ids from resto_order_offer, which is not in the schema and directly affects how to populate 'main' and 'sides'.

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 action on a specific resource: builds an UNPAID cart for one snack-corner formula and returns a summary. It explicitly positions itself as 'Step 1 of 2', which separates it cleanly from resto_order_confirm and resto_order_offer among the siblings.

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 gating condition — only call when the user asked to order food and named items or agreed to a suggestion — plus the required follow-up: show the summary and wait for an explicit yes before resto_order_confirm. The alternative tool and the handoff condition are both named.

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