elevai Commerce Demo

Bestellung anlegen

create_order

Legt im elevai-Demoshop eine Bestellung an und gibt ein Handle zurueck, mit dem sich anschliessend ein Zahllink erzeugen laesst. Beim ersten Aufruf fragt das Werkzeug die Zustimmung zu den Geschaeftsbedingungen zurueck; danach erneut aufrufen mit accept_terms und terms_version. Demoshop mit Grenzen: Einzelpreis bis 0.05 CHF, Bestellsumme bis 0.25 CHF. Was sonst gilt, steht in den Geschaeftsbedingungen, die dieses Werkzeug zurueckgibt — nicht in deiner Antwort wiederholen.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	Die E-Mail-Adresse der Person. Niemals erfinden, niemals einen Platzhalter wie "?" einsetzen — fehlt sie, zuerst danach fragen. Entfaellt, wenn ein bestaetigtes login_handle mitgegeben wird.
`country`	No	Zwei Buchstaben, ISO 3166-1, Vorgabe CH.
`quantity`	No
`last_name`	No
`first_name`	No
`product_id`	Yes	Die id aus search_products.
`accept_terms`	No	Nur true, wenn der Mensch den Geschaeftsbedingungen ausdruecklich zugestimmt hat. Nie selbst setzen.
`login_handle`	No	Das Handle aus start_login, sofern die Person sich im Shop angemeldet hat. Dann wird die Adresse aus dem Konto genommen und nicht erfragt.
`terms_version`	No	Die Fassung, der zugestimmt wurde. Kommt aus der Rueckfrage dieses Werkzeugs.

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes
`status`	Yes
`is_demo`	No
`currency`	Yes
`order_handle`	Yes	Schluessel fuer create_payment_link und get_order_status, zwei Stunden gueltig

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedSep 6, 2026

changedInput schema / properties / email / description

Previous value: -"Die E-Mail-Adresse der Person. Niemals erfinden, niemals einen Platzhalter wie \"?\" einsetzen — fehlt sie, zuerst danach fragen."New value: +"Die E-Mail-Adresse der Person. Niemals erfinden, niemals einen Platzhalter wie \"?\" einsetzen — fehlt sie, zuerst danach fragen. Entfaellt, wenn ein bestaetigtes login_handle mitgegeben wird."

addedInput schema / properties / login_handle

Added value: +{
+  "description": "Das Handle aus start_login, sofern die Person sich im Shop angemeldet hat. Dann wird die Adresse aus dem Konto genommen und nicht erfragt.",
+  "type": "string"
+}

Changed1 schema field changedSep 6, 2026

addedInput schema / properties / email / description

Added value: +"Die E-Mail-Adresse der Person. Niemals erfinden, niemals einen Platzhalter wie \"?\" einsetzen — fehlt sie, zuerst danach fragen."

Changed2 schema fields changedSep 6, 2026

addedInput schema / properties / accept_terms

Added value: +{
+  "description": "Nur true, wenn der Mensch den Geschaeftsbedingungen ausdruecklich zugestimmt hat. Nie selbst setzen.",
+  "type": "boolean"
+}

addedInput schema / properties / terms_version

Added value: +{
+  "description": "Die Fassung, der zugestimmt wurde. Kommt aus der Rueckfrage dieses Werkzeugs.",
+  "type": "string"
+}

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden. It reveals critical behavioral traits: the tool asks back for terms consent on first call, requires a follow-up call with specific parameters, returns a handle for later payment-link creation, and imposes demo price limits. It also tells the agent not to repeat the returned terms, which is a valuable operational instruction.

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?

The description is compact and well-structured: the first sentence states the main action and return value, the second explains the terms flow, and the third sets limits and instructs not to duplicate the terms. Every sentence earns its place, with the most important information front-loaded.

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 complex 9-parameter tool with no annotations, the description covers all essential interaction context: the two-step terms-acceptance flow, the handle's role for later payment-link creation, demo constraints, and where to find the full rules (the terms returned by the tool). Since an output schema exists, return value details need not be spelled out, making the description sufficiently complete.

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 67%, so the baseline is 3. The description adds genuine semantic value beyond the schema by explaining when accept_terms and terms_version should be provided (only after the first call asks for consent) and what the returned handle is for. It does not describe quantity, last_name, or first_name, but these are self-explanatory and the schema already covers the other parameters.

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?

The description uses a specific verb ('Legt ... eine Bestellung an' – creates an order) and identifies the resource (elevai-Demoshop) and the key outcome (returns a handle for generating a payment link). This clearly distinguishes it from siblings like create_payment_link (later step) and get_order_status (status check), leaving no ambiguity about what the tool does.

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?

The description explicitly explains the two-step invocation flow: first call triggers terms consent, then call again with accept_terms and terms_version. It also states concrete boundaries (single price up to 0.05 CHF, order total up to 0.25 CHF), which implicitly tells the agent when the tool is not suitable. This goes beyond context to explicit usage constraints and sequencing.

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

All elevai Commerce Demo tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource or stage: products are searched and read, orders are created and checked, payment links are created, and login has separate start and status tools. The two status tools are clearly separated by domain, so an agent is unlikely to confuse them.

Naming Consistency5/5

All tools use a consistent snake_case verb_noun pattern such as create_order, get_order_status, search_products, and start_login. The action words are specific and the objects are clear, making the expected behavior predictable across the entire set.

Tool Count5/5

Seven tools is well within the ideal range for a focused commerce demo. Each tool covers a necessary step in the demo workflow without redundant additions or unnecessary complexity.

Completeness5/5

The tool surface covers the full demo workflow: product discovery, order creation, payment-link generation, order status checks, and the external login flow. The demo's explicit constraints make the absence of admin operations such as update or delete acceptable, and there are no dead ends.

Resources

Need Help?