alza-mcp

Overview Schema Source Related Servers Discussions Admin

Place an order (legacy web WCF — working path)

web_place_order

Destructive

Place a confirmed Alza order via the working web checkout path, using delivery, payment, contact details, and a one-time token from prepare_mutation.

Instructions

Place an order through the live-verified legacy web WCF checkout pipeline (EShopService.svc: SaveOrder2 → SaveOrder3 → SaveAndConfirmOrder2 with the documented AlzaPlus 113-gate retry → CheckOrder4 → SendOrder4). This is the currently-working order-submission path — the mobile place_order (sendOrder3) returns HTTP 500 (docs/gap-analysis.md G1/G5). Typed inputs only: delivery_id/delivery_group_id from delivery_options, parcel_shop_id from web_pickup_places, payment_id from payment_methods, plus the contact/address block. High-impact, money-relevant: creates a real Alza order — use only with explicit user confirmation, with a one-time token from prepare_mutation (action=web_place_order). Example: web_place_order({delivery_id: 2680, parcel_shop_id: "1128203", payment_id: 103, name: "Jan Novák", street: "Praha 110 00", city: "Praha", zip_code: "110 00", phone: "+420 777 123 456", email: "jan@example.cz", confirmation_token: "..."}).

Input Schema

TableJSON Schema

Name	Required	Description
`city`	Yes	City.
`name`	Yes	Recipient name.
`email`	Yes	Contact email (order confirmation goes here).
`login`	No	Existing login to buy as (defaults to the email).
`phone`	Yes	Contact phone.
`street`	Yes	Street and house number.
`zip_code`	Yes	Postal code.
`quotation`	No	Treat the order as a quotation instead of a purchase. Default false.
`country_id`	No	Country id for the order. Default 0 (server default, CZ).
`payment_id`	Yes	Payment method id (e.g. 103 proforma; from `payment_methods`).
`delivery_id`	Yes	Delivery option id (e.g. 2680 for AlzaBox; from `delivery_options`).
`register_user`	No	Register the buyer as a new account as part of checkout. Default false.
`user_consents`	No	User consent flags verbatim from the checkout context (consent_id → accepted).
`parcel_shop_id`	No	Pickup place id (an AlzaBox parcelShopId from `web_pickup_places`), when delivering to a pickup point.
`basket_consents`	No	Basket-level consent flags verbatim from the checkout context (consent_id → accepted).
`delivery_group_id`	No	Live delivery group id (from `delivery_options`; omit or 0 for the server default).
`confirmation_token`	Yes	One-time token from `prepare_mutation` prepared with the matching action.
`internal_description`	No	Internal order note, if required.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`err`	No
`msg`	No
`data`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description reveals that this tool creates a real Alza order, is high-impact and money-relevant, and goes through a specific multi-step WCF pipeline. It also flags the mobile path failure and the need for user confirmation. These details add substantive behavioral context that the annotations alone do not convey.

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 long but information-dense and appropriately front-loaded. Every element earns its place: the working-path claim, the broken alternative warning, the input provenance rules, the confirmation requirement, and the example. For a high-risk, money-relevant mutation tool, this level of detail is justified and well structured.

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?

The description covers the core purpose, the synchronous operational pipeline, the failure mode of the sibling tool, required user confirmation, token prerequisite, and input sourcing. The schema covers all 18 parameters and an output schema exists, so nothing essential for correct invocation is missing. This is a complete definition for a tool of this 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?

The input schema already documents all 18 parameters, so the baseline is 3. The description adds genuinely useful semantics by telling the agent where parameter values must come from (`delivery_id` from `delivery_options`, `parcel_shop_id` from `web_pickup_places`, `payment_id` from `payment_methods`) and by showing a complete example call. This moves it above baseline.

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 names a specific action ('Place an order through the live-verified legacy web WCF checkout pipeline') and immediately distinguishes this tool from the sibling mobile `place_order`, which returns HTTP 500. It also calls out the exact service chain, making the tool's identity and scope unmistakable. This fully separates it from the many order-adjacent sibling 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?

The description states when to use this tool, explicitly calling it the 'currently-working order-submission path' and cautioning that the mobile alternative is broken. It also provides strong operational constraints: use only with explicit user confirmation, a one-time token from `prepare_mutation`, and typed IDs sourced from specific tools. This is explicit when/why/with-what guidance.

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