elevai Commerce Demo

Server Details

Open demo shop: search products, place a 0.05 CHF order, create a PostFinance payment link.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 35.9% over 56 days
OAuth: Works in Glama
Last Tested: 2026-10-31 04:30
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-10-19 17:05 across 10 tools

Disambiguation4/5

Most tools target clearly distinct operations (order lifecycle, payment, connection info). However search_catalog and search_products are functionally the same catalog search—the description even admits 'same as search_products'—so an agent cannot distinguish between them and may pick either arbitrarily.

Naming Consistency5/5

All ten tools follow a consistent snake_case verb_noun pattern (create_order, get_order_status, list_orders, cancel_order, wait_for_payment, etc.). There is no mixing of conventions or vague verbs.

Tool Count4/5

10 tools is a sensible scope for a demo commerce server covering search, ordering, and payment. The only blemish is the redundant search pair, which means one slot does not really earn its place.

Completeness4/5

The core lifecycle is covered: catalog search, product lookup, order creation, payment link, payment waiting, status check, order listing, cancellation, and connection/capability info. Minor gaps remain—no order modification, no in-tool mandate/connection management (delegated to a web URL), and no refund or return flow—but these are workable for a demo.

Available Tools

10 tools

cancel_orderBestellung stornierenA

DestructiveIdempotent

Inspect

Storniert eine eigene Bestellung, die noch offen oder reserviert ist. Eine Reservation bei PostFinance wird dabei sofort freigegeben (statt erst nach drei Tagen). Nur auf ausdruecklichen Wunsch der Person: erst ohne confirmed_in_chat aufrufen — das Werkzeug nennt, was storniert wuerde —, die Person fragen, und erst nach ihrem Ja mit confirmed_in_chat: true erneut aufrufen. Nur Bestellungen, deren Nummer die Person ausdruecklich nennt; sagt sie «alle» oder nennt keine Nummer, die stornierbaren Nummern aufzaehlen und sie bitten, die gewuenschten Nummern zu nennen. Verlangt das Handle aus create_order oder list_orders (fuer aeltere Bestellungen aus anderen Gespraechen: zuerst list_orders).

Name	Required	Description
`reason`	No	Optional: Grund in den Worten der Person, kurz.
`order_handle`	Yes
`confirmed_in_chat`	No	Nur true, wenn die Person der Stornierung im Gespraech ausdruecklich zugestimmt hat. Nie selbst setzen.

Output Schema

Name	Required	Description
`retry`	No
`total`	No
`status`	No
`currency`	No
`cancelled`	No
`order_handle`	No
`already_cancelled`	No
`reservation_released`	No
`confirmation_required`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description goes further by disclosing a side effect not visible anywhere in structured data — the PostFinance reservation is released immediately instead of after three days — and a mandatory two-step human-confirmation protocol that governs how the tool may be invoked. That is exactly the kind of behavioural context annotations cannot express.

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?

Purpose and the state restriction are front-loaded in sentence one, and each following sentence carries a distinct rule (confirmation flow, no batch cancellation, handle provenance) with no filler. It is however fairly long and dense, with several parallel 'Nur ...' constraints that could be tightened.

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?

An output schema exists, so return values need no explanation, and the description covers everything else an agent needs: prerequisites, the exact confirmation protocol, scope limits, and what to do when the user gives no order number or says 'alle'. Nothing required for a correct call is 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 67% and order_handle has no schema description, so the description compensates by specifying its provenance (output of create_order or list_orders, with list_orders first for older orders) and by defining the invocation semantics of confirmed_in_chat beyond the schema's 'never set yourself' rule. The optional reason parameter is left entirely to the schema and gets no added meaning in the description.

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?

Names a specific verb and resource ('storniert eine eigene Bestellung') and narrows it with a precise state precondition ('noch offen oder reserviert'). It also distinguishes itself from siblings by naming create_order and list_orders as the handle sources, so an agent can place it without opening any other 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?

Gives an explicit call sequence: first invoke without confirmed_in_chat to preview what would be cancelled, ask the person, then re-invoke with confirmed_in_chat: true only after consent. It also states a clear exclusion/handling path — never batch-cancel on 'alle', instead enumerate the cancellable numbers and ask — and names the prerequisite handles and the fallback to list_orders for older orders.

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

create_orderBestellung anlegenAInspect

Legt im elevai-Demoshop eine Bestellung an. Ein Aufruf mit product_id allein genuegt fuer den Anfang: Das Werkzeug prueft selbst, was noch fehlt, und liefert die Geschaeftsbedingungen samt Fassung mit — Nachfragen nach Bedingungen, E-Mail, Namen oder Adresse erledigen sich damit meist von selbst. Fehlt die Zustimmung, steht das in der Antwort; ein zweiter Aufruf mit accept_terms: true und der terms_version aus dieser Antwort schliesst die Bestellung ab (die Fassung stammt immer aus der Antwort, nie aus einer Annahme). Ist der Agent mit einem Kundenkonto verbunden (OAuth), sind Person und Adresse bereits bekannt; liegt zusaetzlich ein Mandat vor, entfaellt die AGB-Rueckfrage ganz. Zurueck kommt ein order_handle fuer create_payment_link; wie es unter einem Mandat weitergeht, steht dort. Demoshop mit Grenzen: Einzelpreis bis 0.05 CHF, Bestellsumme bis 0.25 CHF. Was sonst gilt, steht in den Geschaeftsbedingungen — nicht in deiner Antwort wiederholen.

Name	Required	Description
`email`	No	Nur mitgeben, wenn das Werkzeug in einer vorherigen Antwort ausdruecklich danach gefragt hat. Niemals erfinden, niemals einen Platzhalter wie "?" einsetzen, und nie von sich aus danach fragen. Entfaellt ganz, wenn der Agent mit einem Kundenkonto verbunden ist oder 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	Nur fuer den alten Anmeldeweg ohne OAuth (Werkzeug start_login, einem verbundenen Agenten gar nicht angeboten). Bist du per OAuth verbunden, lass dieses Feld weg — das Konto steht bereits fest.
`terms_version`	No	Die Fassung, der zugestimmt wurde — woertlich aus der Antwort dieses Werkzeugs. Ohne eine solche Antwort gibt es keine Fassung: dann das Werkzeug erst ohne accept_terms aufrufen.

Output Schema

Name	Required	Description
`terms`	No	Wortlaut, Link und Fassung der Geschaeftsbedingungen.
`total`	No
`reason`	No
`status`	No
`is_demo`	No
`mandate`	No
`currency`	No
`order_handle`	No	Schluessel fuer create_payment_link und get_order_status, zwei Stunden gueltig. Fehlt, wenn noch etwas fehlt — siehe terms_required / email_required.
`email_required`	No	Es fehlt eine E-Mail-Adresse.
`terms_required`	No	Es fehlt die Zustimmung zu den Geschaeftsbedingungen. Frag die Person und rufe erneut auf.

TDQS

A4.4/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the mutating, non-idempotent nature is already signaled by structured data. The description adds real context beyond that (demoshop price/sum limits of 0.05/0.25 CHF, that terms come only from the response and never from assumption, that a mandate suppresses the terms prompt), but does not discuss permissions beyond OAuth, failure modes, or what happens on a partial/aborted order. Good added value, though not exhaustive.

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?

The purpose and the two-step completion rule are front-loaded, and each sentence carries operational content (limits, OAuth/mandate behavior, next tool, closing instruction). It is on the long side, with some redundancy around the terms versioning, but no filler sentences.

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, non-idempotent creation tool with an output schema already present, the description supplies everything an agent needs to invoke it correctly: the minimal call, the completion handshake, auth-dependent behavior, limits, and what the returned order_handle feeds into.

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 description coverage is 67%, and the description compensates well for the flow-critical fields: it explains that product_id alone suffices, that accept_terms must only be set after human consent, that terms_version must come verbatim from the prior response, and that email/name/address drop away under OAuth. Undocumented-in-description leftovers (country, quantity, first/last name) are minor and partly covered by the schema.

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 ('Legt im elevai-Demoshop eine Bestellung an') and situates the tool in the ordering flow relative to siblings like create_payment_link and cancel_order. An agent can distinguish it from list_orders/get_order_status 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 says a single call with product_id is enough, that the tool self-checks what is missing, and that a second call with accept_terms: true plus the returned terms_version completes the order. It also names the conditions that remove steps (OAuth account, existing mandate) and points to create_payment_link as the next tool, covering when/when-not and alternatives.

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

create_payment_linkZahllink erzeugenAInspect

Erzeugt zu einer Bestellung eine PostFinance-Checkout-Zahlseite. Verlangt das Handle aus create_order. Der Betrag stammt aus der Bestellung, nicht vom Aufrufer.

Name	Required	Description
`method`	No	Zahlart: pfpay fuer PostFinance Pay. Ohne Angabe liefert das Werkzeug die Zahlart zur Bestaetigung zurueck, statt eine Zahlseite zu erzeugen.
`stepup`	No	Nur true, wenn die Person die Zahlung lieber selbst in der PostFinance App bestaetigen will, statt im Gespraech zuzustimmen. Zusammen mit no_card: liefert den Link zur Zahlseite.
`confirm`	No	Nur von der Zahlkarte selbst gesetzt (Klick auf den Knopf). Nie vom Modell ausfuellen.
`no_card`	No	Nur true, wenn die Person sagt, dass KEINE Zahlkarte und kein Knopf angezeigt wird. Dann liefert das Werkzeug einen Link zur Zahlseite (Bestaetigung in der PostFinance App) — auch unter einem Mandat mit Direktzahlung. Sonst weglassen.
`unattended`	No	Nur true bei einer autonomen, geplanten Aufgabe, bei der KEIN Mensch im Gespraech ist. Dann bucht ein Mandat mit Direktzahlung ohne Klick. Ist eine Person im Chat, IMMER weglassen.
`order_handle`	Yes	Das Handle aus create_order.
`request_approval`	No	Nur aus der Zahlkarte. Stoesst die Freigabe in der PostFinance App an, ohne eine Seite zu oeffnen. Verlangt eine Bestellung, fuer die schon ein Zahllink erzeugt wurde.
`confirmed_in_chat`	No	Nur true, wenn die Person im Gespraech soeben ausdruecklich Ja gesagt hat auf deine Frage, ob jetzt bezahlt werden soll. Gilt nur unter einem Mandat mit Direktzahlung und nur zusammen mit no_card. Nie selbst setzen, nie annehmen, nie aus dem Zusammenhang erschliessen.

Output Schema

Name	Required	Description
`note`	No
`paid`	No
`state`	No
`total`	No
`direct`	No	Mandat erlaubt die Zahlung ohne Bestaetigung in der App.
`method`	No
`stepup`	No
`is_paid`	No
`methods`	No
`currency`	No
`mandate_id`	No
`order_line`	No	Was bestellt wurde, fuer die Karte.
`is_reserved`	No
`mandate_url`	No
`method_name`	No
`payment_url`	No	Link zur Zahlseite; erst in der Antwort MIT Zahlart enthalten
`shipping_to`	No
`fallback_url`	No
`mandate_name`	No
`order_handle`	No
`choice_required`	No	Die Karte zeigt den Knopf; gebucht wird erst beim Tippen.
`approval_requested`	No	Die Freigabe wurde an die PostFinance App geschickt.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent already knows this is a non-destructive mutating call. The description adds one genuine behavioral fact beyond that: the amount is taken from the order rather than supplied by the caller. It does not say whether repeated calls reuse or create new links, nor what the call returns (though an output schema exists).

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 compact sentences, front-loaded with what the tool produces, then the prerequisite, then the amount-scoping constraint. No filler or redundancy.

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?

With an output schema present, return values need not be explained, and the annotations cover the safety profile. The description supplies the essential prerequisite and the amount-derivation rule, leaving only minor gaps such as the behavior of the method-confirmation fallback, which the schema itself documents.

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 the schema already documents all eight parameters, including the order_handle's origin. The description's only parameter-relevant contribution is repeating that the handle comes from create_order and that no amount parameter exists. Baseline 3 is appropriate when the schema carries the semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Erzeugt zu einer Bestellung eine PostFinance-Checkout-Zahlseite'), so the agent knows it produces a checkout payment page tied to an existing order. It also names the upstream dependency (create_order) and clarifies the scope boundary that the amount is derived from the order. It does not explicitly differentiate itself from siblings like wait_for_payment or cancel_order, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives one clear prerequisite: the order handle must come from create_order. However, it offers no when-to-use/when-not-to-use guidance and does not point to alternatives among the eight siblings. The richer conditional guidance (no_card, stepup, unattended, confirmed_in_chat) lives entirely in the schema, not the description.

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

get_connectionVerbindung und Mandat anzeigenAInspect

Zeigt, mit welchem Kundenkonto dieser Agent verbunden ist und was er darf: Mandat, Hoechstbetraege, verbrauchtes Monatsbudget, freigegebene Kategorien, Art der Zahlungsfreigabe, Laufzeit. Aufrufen, wenn die Person fragt, was der Agent darf, oder bevor eine Bestellung an einer Grenze scheitern koennte. Mandat anlegen, aendern, widerrufen oder Verbindung trennen: https://elevai.ch/demos/woo-shop/wordpress/my-account/agenten/?von=chat

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`account`	No	Das Kundenkonto im Shop, mit dem diese Verbindung zugelassen wurde.
`mandate`	No
`connected`	No
`manage_url`	No

TDQS

A4.1/5.0

Behavior3/5

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

No annotations exist, so the description carries the full behavioral burden. 'Zeigt' implies a read, and the 'before an order could fail at a limit' note adds real context, but it never states permissions/auth requirements or that the operation is side-effect free. The field enumeration largely duplicates the output schema.

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 what is returned, then the when-to-use trigger, then a link for mandate CRUD. Every sentence earns its place; the URL is long but routes the agent to the right place for unsupported write operations.

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?

With an output schema present, return values need not be spelled out, and the description still covers purpose, trigger, and where to go for mandate changes. Nothing essential for calling this zero-arg read tool is 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?

The tool takes zero parameters, so there is nothing to misinterpret and the baseline of 4 applies. No parameter documentation is needed.

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?

Names a specific verb+resource (shows which customer account this agent is connected to) and enumerates exactly what it reveals: mandate, maximum amounts, monthly budget, released categories, approval type, runtime. This clearly separates it from the order/product siblings.

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 an explicit trigger ('when the person asks what the agent may do, or before an order could fail at a limit'), which is genuinely useful routing. It does not contrast with any sibling tool, but the mandate-management actions are correctly pointed to an external URL rather than a sibling.

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

get_order_statusBestellstatus abfragenA

Read-onlyIdempotent

Inspect

Zeigt den aktuellen Stand einer Bestellung. In dieser Demo ist "reserviert" (on-hold) der Endzustand: der Betrag wird nie eingezogen und die Reservation faellt nach drei Tagen weg. Verlangt das Handle aus create_order.

Name	Required	Description	Default
`order_handle`	Yes

Output Schema

Name	Required	Description
`total`	No
`status`	Yes
`created`	No
`is_paid`	Yes
`currency`	No
`order_handle`	No
`cancelled_on_request`	No
`reservation_released`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuine domain behavior: 'on-hold' is terminal, the amount is never charged, and the reservation expires after three days. That is exactly the kind of behavioral context an agent can't get from the annotations.

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?

Three short sentences, front-loaded with the purpose before the demo caveat and the prerequisite. Tight and without filler, though the mixed-language framing is slightly abrupt.

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?

An output schema exists, so return values need not be explained. Combined with the terminal-state behavior note and the handle provenance, the definition gives an agent enough to call the tool correctly, missing only alternative-routing guidance.

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 description coverage is 0%, so the description must compensate for the single 'order_handle' parameter. It does so by stating where the handle comes from ('aus create_order'), which is the key semantic an agent needs even though field format isn't specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Zeigt den aktuellen Stand einer Bestellung'), so the agent immediately knows this is a read of order state. It doesn't explicitly name or contrast with siblings like list_orders or wait_for_payment, so differentiation relies on the agent's own inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides one useful prerequisite ('Verlangt das Handle aus create_order') that ties it to the create flow, and clarifies the demo's terminal state. It gives no explicit guidance on when to prefer this over wait_for_payment or list_orders, so usage is only implied.

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

get_productProdukt ansehenA

Read-onlyIdempotent

Inspect

Liefert die Einzelheiten zu einem Produkt: Beschreibung, Preis, Lagerstatus, Kategorien und Bild.

Name	Required	Description	Default
`product_id`	Yes	Die id aus search_products.

Output Schema

Name	Required	Description
`id`	Yes	product_id fuer create_order
`url`	No
`name`	Yes
`image`	No
`price`	Yes
`currency`	Yes
`in_stock`	No

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the payload contents, which is mild added value, but says nothing about failure behaviour (e.g. unknown product_id) or rate limits.

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?

A single, front-loaded sentence with no filler. The field enumeration partially duplicates the existing output schema, which slightly reduces the value of the wording, but the sentence is otherwise tight.

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 simple idempotent read with full annotations, one required parameter and an output schema, the description covers purpose and result contents adequately. Only error/not-found behaviour is absent, which is a minor gap given the output schema exists.

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 the single parameter is already documented, including the useful cross-reference to search_products. The description contributes no additional parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (returns the details of a product) and enumerates the fields returned: description, price, stock status, categories and image. It does not explicitly name search_products as the discovery sibling in the description text, so differentiation is implied rather than stated, which keeps it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, nor a named alternative. The flow is only inferable (retrieve details once you have a product), and the crucial hint 'Die id aus search_products' lives in the schema parameter, not the description.

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

list_ordersEigene Bestellungen auflistenA

Read-onlyIdempotent

Inspect

Listet die Bestellungen, die Agenten fuer das verbundene Kundenkonto angelegt haben (letzte sieben Tage, neueste zuerst), je mit einem frischen order_handle. Damit lassen sich auch aeltere Bestellungen aus anderen Gespraechen finden, ihr Stand abfragen (get_order_status) und offene oder reservierte stornieren (cancel_order). Bezahlen laesst sich nur eine Bestellung, die hoechstens zwei Stunden alt ist.

Name	Required	Description	Default
`limit`	No	Vorgabe 10.
`status`	No	open: nur offene und reservierte (stornierbar). Vorgabe: all.

Output Schema

Name	Required	Description
`orders`	Yes
`account`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real behavioral information beyond them: a seven-day lookback window, newest-first ordering, a fresh order_handle issued on each call (implying non-stable identifiers), and the two-hour payment eligibility limit.

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?

Purpose and scope are front-loaded in the first clause, and the second sentence earns its place by routing to get_order_status/cancel_order and giving the payment age constraint. Slightly dense, but no filler.

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?

An output schema exists, so return values need not be described. Window, ordering, follow-up tools and the payment-age caveat are all covered; only pagination/limit interaction and how the seven-day window behaves relative to the limit parameter are left implicit.

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% and both parameters (limit, status) are documented in the schema. The description hints at the status semantics (open/reserved, cancellable) and the default ordering, but adds no syntax or format detail beyond the schema, so the baseline of 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?

Specific verb+resource ("Listet die Bestellungen ... fuer das verbundene Kundenkonto") with explicit scope (last seven days, newest first) and the returned artifact (fresh order_handle). It also names sibling tools (get_order_status, cancel_order) so the agent can distinguish this retrieval tool from its follow-ups.

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?

It states the practical use case (finding older orders from other conversations), which successor tools to call, and the boundary condition that only orders up to two hours old can be paid. No explicit 'do not use this for X' exclusion, but the routing context is clear.

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

search_catalogSearch catalogA

Read-onlyIdempotent

Inspect

Search the product catalog des elevai-Demoshops by keyword (UCP name; same as search_products). Returns id, name, price, currency, stock and product URL. Without a query: the newest products. No sign-in needed. The id is the product_id for get_product and create_order.

Name	Required	Description	Default
`limit`	No
`query`	No	Suchbegriff, etwa "Kite" oder "Abo".

Output Schema

Name	Required	Description
`count`	Yes
`products`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavior: no authentication required, and the no-query fallback returning the newest products, which is not derivable from the annotations or schema.

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?

Four short sentences, front-loaded with the core verb and scope, then return fields, fallback behavior, and auth. The 'same as search_products' clause is arguably redundant since a sibling of that name already exists.

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?

An output schema exists, so return-value explanation is not strictly required, yet the description still names the key fields. Combined with auth requirements, empty-query behavior, and the id-to-product_id linkage, an agent has enough to call it correctly; only the limit parameter is left unaddressed.

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 coverage is only 50% (the query param is described, limit is not). The description compensates partially by explaining the empty-query case and the keyword nature of the search, but says nothing about the limit parameter's default or the 1–20 cap, so it neither fully compensates nor adds much beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Search the product catalog ... by keyword'. It also names the sibling relationship ('same as search_products'), which tells the agent what the tool is but not how it differs, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real usage context — 'Without a query: the newest products' and 'No sign-in needed' — which tells the agent what happens with an empty call. However, saying it is 'same as search_products' without saying when to prefer one over the other leaves the choice ambiguous rather than resolved.

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

search_productsProdukte suchenB

Read-onlyIdempotent

Inspect

Durchsucht den Katalog des elevai-Demoshops nach einem Begriff und liefert Name, Preis, Waehrung und Produktseite. Ohne Begriff kommen die zuletzt aufgenommenen Produkte.

Name	Required	Description	Default
`limit`	No
`query`	No	Suchbegriff, etwa "Kite" oder "Abo".

Output Schema

Name	Required	Description
`count`	Yes
`products`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact outside structured data — the empty-query fallback returns recently added products — but says nothing about result caps, pagination, or the meaning of limit.

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?

Two tight sentences with the verb+resource front-loaded and the fallback behavior second. The enumeration of return fields is mildly redundant given an output schema exists, but nothing is padded and the ordering is logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema covering return values and annotations covering safety, the description only needs to clarify the fallback and positioning, which it partly does. The notable gap is that a 10-sibling toolbox contains both search_catalog and get_product with no stated boundary, leaving the agent to guess which search tool to invoke.

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 50%: query is documented with examples ('Kite', 'Abo') while limit is undocumented anywhere. The description's 'Begriff' restates the query concept but adds no format or semantics beyond the schema, and the limit parameter that controls result count (default 10, max 20) is never explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource ('Durchsucht den Katalog des elevai-Demoshops') and states what is returned (Name, Preis, Waehrung, Produktseite), so the intent is unambiguous. It fails to distinguish itself from the similarly named sibling search_catalog or from get_product, so an agent could still hesitate between the three.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies a usage mode by explaining the no-query fallback ('Ohne Begriff kommen die zuletzt aufgenommenen Produkte'), which tells the agent it can be used to browse recent products. However, there is no explicit when-to-use guidance and no mention of how it differs from search_catalog or get_product.

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

wait_for_paymentAuf den Zahlungseingang wartenA

Read-onlyIdempotent

Inspect

Haelt die Anfrage offen, bis die Zahlung zu einer Bestellung eingetroffen ist, und meldet dann den Endstand. Eine Runde dauert rund 25 Sekunden; kommt in dieser Zeit nichts an, ist das KEIN Fehler, sondern das Zeichen, sofort die naechste Runde zu starten (hoechstens 5 hintereinander, mit hochgezaehltem attempt). Sinnvoll direkt nach create_payment_link, sobald die Zahlungsaufforderung im Gespraech steht. Grund: Der Chat erfaehrt von einer Zahlung nichts von selbst, und die Bestaetigungsseite von PostFinance fuehrt nicht hierher zurueck. Wer waehrend des Wartens bezahlt und dann in den Chat zurueckkehrt, findet die Bestaetigung bereits vor. Verlangt das Handle aus create_order.

Name	Required	Description
`attempt`	No	Die wievielte Warterunde das ist. Erste Runde 1, danach hochzaehlen. Das Werkzeug sagt selbst, wann Schluss ist.
`max_seconds`	No	Wie lange eine Runde warten soll. Ohne Angabe 25 Sekunden — nicht erhoehen, der Webserver schneidet laengere Anfragen ab.
`order_handle`	Yes

Output Schema

Name	Required	Description
`total`	No
`status`	Yes
`attempt`	No
`created`	No
`is_paid`	Yes
`currency`	No
`is_final`	No
`timed_out`	No
`is_reserved`	No
`order_handle`	No
`attempts_left`	No
`waited_seconds`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover only the safety profile (readOnly, idempotent, non-destructive), leaving the most important trait to the description: this is a long-blocking call with a ~25s round, a 90s server-side ceiling, and a 5-attempt retry protocol. That retry/timeout semantics is exactly what an agent needs and what nothing else provides.

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-loaded with the core behavior, then the retry protocol, then the rationale and precondition. Dense rather than padded, but the six-sentence length is near the upper bound for a single tool; the PostFinance explanation could be tightened.

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?

An output schema exists, so return values are not the description's burden, and it still signals that a final state is reported. For a blocking, retry-looped tool with non-obvious failure semantics, the description supplies everything needed to invoke it 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 67%: attempt and max_seconds are documented in the schema, but order_handle is bare, and the description compensates by pinning its origin ('Verlangt das Handle aus create_order'). It also reinforces the attempt increment and the warning against raising max_seconds beyond the webserver truncation point, adding rationale the schema only states flatly.

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+resource: it holds the request open until a payment for an order has arrived, then reports the final state. This is clearly distinguishable from siblings like get_order_status (a non-blocking query) and create_payment_link (which initiates).

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?

Names the trigger condition explicitly ('sinnvoll direkt nach create_payment_link, sobald die Zahlungsaufforderung im Gespraech steht') and explains why no alternative exists ('Der Chat erfaehrt von einer Zahlung nichts von selbst'). It also pre-empts a likely misuse: an empty 25-second round is not an error but a signal to start the next round, capped at 5 attempts.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 17, 2026
- Addedsearch_catalog

9 tool updatesOct 16, 2026

Addedcancel_order

Changedcreate_order11 fields changed

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. Entfaellt, wenn ein bestaetigtes login_handle oder ein mandate_key mitgegeben wird."New value: +"Nur mitgeben, wenn das Werkzeug in einer vorherigen Antwort ausdruecklich danach gefragt hat. Niemals erfinden, niemals einen Platzhalter wie \"?\" einsetzen, und nie von sich aus danach fragen. Entfaellt ganz, wenn der Agent mit einem Kundenkonto verbunden ist oder ein bestaetigtes login_handle mitgegeben wird."

changedInput schema / properties / login_handle / description

Previous value: -"Das Handle aus start_login, sofern die Person sich im Shop angemeldet hat. Dann wird die Adresse aus dem Konto genommen und nicht erfragt."New value: +"Nur fuer den alten Anmeldeweg ohne OAuth (Werkzeug start_login, einem verbundenen Agenten gar nicht angeboten). Bist du per OAuth verbunden, lass dieses Feld weg — das Konto steht bereits fest."

removedInput schema / properties / mandate_key

Removed value: -{
-  "description": "Der Agentenschluessel (ek_ und 32 Zeichen), den die Person im Gespraech genannt hat. Nur weitergeben, was die Person wirklich geschrieben hat — nie raten, nie aus einem frueheren Gespraech uebernehmen. Mit gueltigem Schluessel bestellt der Agent im Namen der Person innerhalb ihres Mandats: an die hinterlegte Adresse, in den freigegebenen Kategorien, bis zu ihren Limiten.",
-  "type": "string"
-}

changedInput schema / properties / terms_version / description

Previous value: -"Die Fassung, der zugestimmt wurde. Kommt aus der Rueckfrage dieses Werkzeugs."New value: +"Die Fassung, der zugestimmt wurde — woertlich aus der Antwort dieses Werkzeugs. Ohne eine solche Antwort gibt es keine Fassung: dann das Werkzeug erst ohne accept_terms aufrufen."

addedOutput schema / properties / email_required

Added value: +{
+  "description": "Es fehlt eine E-Mail-Adresse.",
+  "type": "boolean"
+}

addedOutput schema / properties / mandate
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / order_handle / description

Previous value: -"Schluessel fuer create_payment_link und get_order_status, zwei Stunden gueltig"New value: +"Schluessel fuer create_payment_link und get_order_status, zwei Stunden gueltig. Fehlt, wenn noch etwas fehlt — siehe terms_required / email_required."

addedOutput schema / properties / reason
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / terms

Added value: +{
+  "description": "Wortlaut, Link und Fassung der Geschaeftsbedingungen.",
+  "type": "object"
+}

addedOutput schema / properties / terms_required

Added value: +{
+  "description": "Es fehlt die Zustimmung zu den Geschaeftsbedingungen. Frag die Person und rufe erneut auf.",
+  "type": "boolean"
+}

removedOutput schema / required

Removed value: -[
-  "order_handle",
-  "status",
-  "total",
-  "currency"
-]

Changedcreate_payment_link26 fields changed

addedInput schema / properties / confirm

Added value: +{
+  "description": "Nur von der Zahlkarte selbst gesetzt (Klick auf den Knopf). Nie vom Modell ausfuellen.",
+  "type": "string"
+}

addedInput schema / properties / confirmed_in_chat

Added value: +{
+  "description": "Nur true, wenn die Person im Gespraech soeben ausdruecklich Ja gesagt hat auf deine Frage, ob jetzt bezahlt werden soll. Gilt nur unter einem Mandat mit Direktzahlung und nur zusammen mit no_card. Nie selbst setzen, nie annehmen, nie aus dem Zusammenhang erschliessen.",
+  "type": "boolean"
+}

addedInput schema / properties / no_card

Added value: +{
+  "description": "Nur true, wenn die Person sagt, dass KEINE Zahlkarte und kein Knopf angezeigt wird. Dann liefert das Werkzeug einen Link zur Zahlseite (Bestaetigung in der PostFinance App) — auch unter einem Mandat mit Direktzahlung. Sonst weglassen.",
+  "type": "boolean"
+}

addedInput schema / properties / request_approval

Added value: +{
+  "description": "Nur aus der Zahlkarte. Stoesst die Freigabe in der PostFinance App an, ohne eine Seite zu oeffnen. Verlangt eine Bestellung, fuer die schon ein Zahllink erzeugt wurde.",
+  "type": "boolean"
+}

addedInput schema / properties / stepup

Added value: +{
+  "description": "Nur true, wenn die Person die Zahlung lieber selbst in der PostFinance App bestaetigen will, statt im Gespraech zuzustimmen. Zusammen mit no_card: liefert den Link zur Zahlseite.",
+  "type": "boolean"
+}

addedInput schema / properties / unattended

Added value: +{
+  "description": "Nur true bei einer autonomen, geplanten Aufgabe, bei der KEIN Mensch im Gespraech ist. Dann bucht ein Mandat mit Direktzahlung ohne Klick. Ist eine Person im Chat, IMMER weglassen.",
+  "type": "boolean"
+}

addedOutput schema / properties / approval_requested

Added value: +{
+  "description": "Die Freigabe wurde an die PostFinance App geschickt.",
+  "type": "boolean"
+}

addedOutput schema / properties / choice_required

Added value: +{
+  "description": "Die Karte zeigt den Knopf; gebucht wird erst beim Tippen.",
+  "type": "boolean"
+}

addedOutput schema / properties / direct

Added value: +{
+  "description": "Mandat erlaubt die Zahlung ohne Bestaetigung in der App.",
+  "type": "boolean"
+}

addedOutput schema / properties / fallback_url
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / is_paid
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / is_reserved
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / mandate_id
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / mandate_name
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / mandate_url
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / method
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / method_name
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / methods

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / order_line

Added value: +{
+  "description": "Was bestellt wurde, fuer die Karte.",
+  "type": "string"
+}

addedOutput schema / properties / paid
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / properties / payment_url / description

Previous value: -"Vollstaendiger Link zur PostFinance-Zahlseite, unveraendert ausgeben"New value: +"Link zur Zahlseite; erst in der Antwort MIT Zahlart enthalten"

addedOutput schema / properties / shipping_to
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / state
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / stepup
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / total
```
Added value: +{
+  "type": "string"
+}
```
removedOutput schema / required
```
Removed value: -[
-  "payment_url"
-]
```

Addedget_connection
Removedget_login_status
Changedget_order_status2 fields changed
- addedOutput schema / properties / cancelled_on_request
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / reservation_released
```
Added value: +{
+  "type": "boolean"
+}
```
Addedlist_orders
Removedstart_login
Addedwait_for_payment

1 tool updateSep 11, 2026

Changedcreate_order3 fields changed

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. Entfaellt, wenn ein bestaetigtes login_handle mitgegeben wird."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 oder ein mandate_key mitgegeben wird."

addedInput schema / properties / mandate_key

Added value: +{
+  "description": "Der Agentenschluessel (ek_ und 32 Zeichen), den die Person im Gespraech genannt hat. Nur weitergeben, was die Person wirklich geschrieben hat — nie raten, nie aus einem frueheren Gespraech uebernehmen. Mit gueltigem Schluessel bestellt der Agent im Namen der Person innerhalb ihres Mandats: an die hinterlegte Adresse, in den freigegebenen Kategorien, bis zu ihren Limiten.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "product_id",
-  "email"
-]New value: +[
+  "product_id"
+]

1 tool updateSep 9, 2026

Changedcreate_payment_link2 fields changed

changedInput schema / properties / method / description

Previous value: -"Zahlart: pfpay fuer PostFinance Pay, twint fuer TWINT. Ohne Angabe liefert das Werkzeug die Auswahl zurueck, statt eine Zahlseite zu erzeugen."New value: +"Zahlart: pfpay fuer PostFinance Pay. Ohne Angabe liefert das Werkzeug die Zahlart zur Bestaetigung zurueck, statt eine Zahlseite zu erzeugen."

changedInput schema / properties / method / enum

Previous value: -[
-  "pfpay",
-  "twint"
-]New value: +[
+  "pfpay"
+]

3 tool updatesSep 6, 2026

Changedcreate_order2 fields changed

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"
+}

Addedget_login_status
Addedstart_login

1 tool updateSep 6, 2026

Changedcreate_payment_link1 field changed

addedInput schema / properties / method

Added value: +{
+  "description": "Zahlart: pfpay fuer PostFinance Pay, twint fuer TWINT. Ohne Angabe liefert das Werkzeug die Auswahl zurueck, statt eine Zahlseite zu erzeugen.",
+  "enum": [
+    "pfpay",
+    "twint"
+  ],
+  "type": "string"
+}

1 tool updateSep 6, 2026

Changedcreate_order1 field changed

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."

1 tool updateSep 6, 2026

Changedcreate_order2 fields changed

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"
+}

5 tool updatesSep 6, 2026
- First observedcreate_order
- First observedcreate_payment_link
- First observedget_order_status
- First observedget_product
- First observedsearch_products

Related MCP Connectors

LotsStoreOAuth
app.lotsstore
Your online store: products, stock, orders, customers and payments into your own account.
E-commerce & Retail Payments & Billing
1
https://api.lotsstore.app/mcp
LotsCommerceOAuth
com.lotscommerce
Your online store: products, stock, orders, customers and payments into your own account.
E-commerce & Retail Payments & Billing
1
https://api.lotscommerce.com/mcp
BugTape demo A
ai.bugtape
Read-only sample shop with captured bug evidence. No account or key needed.
E-commerce & Retail Testing & QA Tools
141
https://app.bugtape.ai/demo/mcp
store A
dev.pages.datanest-stores
Search and preview Datanest developer products, then prepare buyer-authorized Stripe Checkout.
E-commerce & Retail Developer Tools
71
https://datanest-stores.com/mcp

Related MCP Servers

Portage
E-commerce & Retail Payments & Billing
tomtom87
A
license
A
quality
A
maintenance
A shopper’s agent searches stores, compares prices and buys with the shopper’s approval.
Updated 9 days ago (2026-10-22 06:01 UTC)
2
14
2
MIT
Commerce MCP Server
E-commerce & Retail Search Autonomous Agents
NewPlanetWW
F
license
Not graded
quality
D
maintenance
Enables AI agents to browse product catalogs, search products with filters, and initiate checkouts, generating order summaries and checkout URLs.
Updated 5 months ago (2026-05-24 00:43 UTC)
-
ShopScout
E-commerce & Retail
forgemeshlabs
A
license
A
quality
A
maintenance
Let your agent find, shop and compare. Shopify Global Catalog search, offer ranking and shipping-plan comparison, $0.01 USDC per call via x402 on Base. No API key, no purchases.
Updated 8 days ago (2026-10-23 13:21 UTC)
5
59 npm
MIT
Doorway
E-commerce & Retail Payments & Billing
cloudy070
A
license
Not graded
quality
C
maintenance
Exposes an owner-reviewed, server-validated merchant catalog as MCP shopping tools that let an agent fetch store details, search products, check availability, build a cart, and start a checkout that hands a capability-protected link to a human for PayPal sandbox approval. Pricing, inventory, discounts and payee remain server-owned, and no capture, refund or publication tools are exposed.
Updated 7 days ago (2026-10-23 22:44 UTC)
2 npm
MIT

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?