elevai Commerce Demo

Zahllink erzeugen

create_payment_link

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`method`	No	Zahlart: pfpay fuer PostFinance Pay, twint fuer TWINT. Ohne Angabe liefert das Werkzeug die Auswahl zurueck, statt eine Zahlseite zu erzeugen.
`order_handle`	Yes	Das Handle aus create_order.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`currency`	No
`payment_url`	Yes	Vollstaendiger Link zur PostFinance-Zahlseite, unveraendert ausgeben
`order_handle`	No

Schema Changelog

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

Changed1 schema field changedSep 6, 2026

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

First observedSep 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Die Beschreibung geht über die reine Funktionsangabe hinaus und offenbart relevante Verhaltensdetails: Es wird ein Handle benötigt, der Betrag stammt aus der Bestellung und ohne method-Angabe wird keine Zahlseite erzeugt, sondern eine Auswahl geliefert. Damit wird das Verhalten besonders im Grenzfall transparent.

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?

Die Beschreibung ist mit zwei Sätzen kompakt und informationdicht. Die wesentliche Information (Erzeugt Zahlseite, benötigt Handle, Betrag aus Bestellung) steht vorne, und jede Aussage trägt zur korrekten Verwendung bei.

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?

Für ein Werkzeug mit zwei Parametern, vollständigem Schema und Output-Schema ist die Beschreibung ausreichend vollständig. Es fehlen nur marginale Aspekte wie mögliche Fehlerfälle oder Authentifizierungsdetails, die aber nicht zwingend erforderlich sind.

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?

Die Schema-Beschreibung deckt beide Parameter vollständig ab, insbesondere den method-Parameter mit Enum und Verhaltensbeschreibung. Die Tool-Beschreibung ergänzt den Kontext, dass das Handle aus create_order stammt und den Betrag eben nicht der Aufrufer bestimmt.

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?

Beschreibt mit spezifischem Verb ('erzeugt') und Ressource ('PostFinance-Checkout-Zahlseite') klar die Funktion. Der Zusatz, dass der Betrag aus der Bestellung stammt und nicht vom Aufrufer, grenzt die Funktionalität von anderen Werkzeugen ab und macht den Zweck eindeutig.

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?

Die Beschreibung nennt explizit die Abhängigkeit vom Handle aus create_order und das optionale Verhalten ohne method-Angabe. Damit ist klar, wann das Werkzeug genutzt werden soll und was bei bestimmten Eingaben passiert.

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?