Yango Tech Retail MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| YANGO_DOMAIN | No | Alias for YANGO_RETAIL_API_BASE_URL. | |
| ASKADS_TELEMETRY | No | Set to '0' to opt out of anonymous usage pings. | |
| YANGO_AUTH_TOKEN | No | Alias for YANGO_RETAIL_TOKEN. | |
| YANGO_API_BASE_URL | No | Alias for YANGO_RETAIL_API_BASE_URL. | |
| YANGO_RETAIL_TOKEN | No | Bearer token issued by Yango Tech for your retailer account. Treat as a secret. Alternatively, YANGO_AUTH_TOKEN can be used. | |
| YANGO_RETAIL_TIMEOUT_MS | No | Per-request timeout in milliseconds. Default: 60000. | |
| YANGO_RETAIL_MAX_RETRIES | No | Retries on transient errors (429 always; 5xx/network for reads only). Default: 3. | |
| YANGO_RETAIL_API_BASE_URL | No | API root override. Default: https://api.retailtech.yango.com. Aliases: YANGO_API_BASE_URL, YANGO_DOMAIN. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_orderA | Creates an order on the Yango Tech platform (POST /b2b/v1/orders/create). You supply the order_id; the same body shape is used by the platform for order updates. All money fields are decimal STRINGS (e.g. "150.00"), never numbers. The response body is not documented upstream and is returned verbatim. After creation, track progress with get_orders_state (get_order does NOT return the state). |
| cancel_orderA | Cancels an existing order (POST /b2b/v1/orders/cancel). Optionally pass a reason. The response body is not documented upstream and is returned verbatim; verify the outcome with get_orders_state (expect canceled or pending_cancel). |
| get_orderA | Details of a single order (POST /b2b/v1/orders/get): every field the order was created with (cart, delivery_address, payment_type, store_id, …) plus create_time. NOTE: the response does NOT include the order state — use get_orders_state for tracking. |
| get_orders_stateA | Batch order tracking (POST /b2b/v1/orders/state). Returns {query_results: [{order_id, query_result, state?}]} — query_result reports per-order lookup success (an unknown id is reported here, not as an HTTP error). Known states: draft, checked_out, reserving, reserved, postpone_reserving, postponed, assembling, assembled, courier_assigned, delivering, closed, pending_cancel, canceled (the list is open-ended). |
| query_order_eventsA | Cursor-based order event feed (POST /b2b/v1/orders/events/query): new orders, state changes and issued receipts. Returns {cursor, orders_events: [{order_id, occurred, data: {type, …}}]} where data.type is state_change (with current_state), new_order, or receipt_issued (with receipt_id). Omit cursor for the first call, then keep passing the returned cursor — the feed is continuous, so poll again later with the last cursor. |
| get_receiptA | Fiscal receipt(s) by receipt id OR order id (POST /b2b/v1/receipts/get) — pass exactly one of the two. Returns {receipts: [{receipt_id, order, create_time, store, receipt_type (payment|refund), payment_methods, items, client?}]}; items is a map keyed by item id, and all amounts are decimal strings. Client PII (full_name, phone_number, email, delivery_address) is included only for the fields you list in client_fields. |
| get_storesA | All stores (darkstores) of the retailer (POST /b2b/v1/stores/get, no parameters). Returns {stores: [{id, status, location: {lat, lon}, address?, name?}]}. The store id is the WMS store id used by create_order, update_stocks and create_discounts; status values are not enumerated upstream. |
| query_productsA | Cursor-based product catalog / product-updates feed (POST /b2b/v1/products/query). Returns {products, cursor}; iterate until a page has fewer items than limit to build a full snapshot. Each product: {product_id, master_category, status (active|disabled|archived), is_meta, custom_attributes}. custom_attributes carries localized maps (longName, shortNameLoc, descriptionLoc: {lang: text}), markCount + markCountUnitList (unit/gram/kilogram/liter/millilitre — open-ended), barcode[], images[], typeAccounting (byUnit|byWeight|byTrueWeight) and arbitrary extra attributes. |
| create_productsA | Creates (or upserts) products in the catalog (POST /b2b/v1/products/create), at most 100 per request. Each product uses the same shape query_products returns: {product_id, master_category, status, is_meta, custom_attributes}. custom_attributes must include longName ({lang: text}), shortNameLoc, markCount and markCountUnitList; extra keys are passed through. The response body is not documented upstream (2xx = success) and is returned verbatim. |
| query_price_listsA | Cursor-based price-list feed (POST /b2b/v1/pricelists/query) — the API's only way to list price lists, so a full snapshot means iterating until a page has fewer items than limit. Returns {pricelists: [{id, name, status (active|removed)}], cursor}. Price-list ids feed get_prices and set_prices. Related endpoints without a dedicated tool (pricelists/get, pricelists/create, store-pricelist-links/*) are reachable via raw_request. |
| get_pricesA | Product prices for one or more price lists (POST /b2b/v1/prices/get). Returns {results: [{pricelist_id, prices_data: [{product_id, price, price_per_quantity?}]}]}. price may arrive as a number or a string — treat it as a decimal either way. |
| set_pricesA | Sets product prices in price lists (POST /b2b/v1/prices/set), at most 100 per request. Prices are decimal STRINGS (e.g. "150.00"); price_per_quantity (pack size the price applies to) defaults to 1 when omitted. The response body is not documented upstream (2xx = success) and is returned verbatim. There is no delete endpoint for prices. |
| create_discountsA | Creates per-store product discounts (POST /b2b/v1/discounts/create), at most 100 per request. CAUTION: the exact key names inside discount_activity_period and discount_value are NOT documented (the official client types them as plain string→string maps with no example) — confirm the expected keys with Yango Tech before relying on this tool, and note there is no endpoint to list or delete discounts. The response body is not documented upstream (2xx = success) and is returned verbatim. |
| query_stocksA | Cursor-based stock feed across stores (POST /b2b/v1/stocks/query). Returns {stocks: [{product_id, quantity, shelf_type, store_id}], cursor}; iterate until a page has fewer items than limit for a full snapshot. Known shelf_type values (open-ended): store, markdown, incoming, out, trash, lost, found, office, parcel, parcel_returned, collection, cargo, repacking, review, kitchen_on_demand, kitchen_components, kitchen_trash, kitchen_lost, kitchen_found. Sellable stock normally lives on shelf_type "store". |
| update_stocksA | Writes stock quantities for one store. mode=modify (default) POSTs /b2b/v1/stocks/update with update_mode "modify" (at most 1000 items per request); mode=initialize POSTs /b2b/v1/stocks/initialize for the first-time stock load of a store. The response body is not documented upstream (2xx = success) and is returned verbatim. Verify the result with query_stocks. |
| raw_requestA | Escape hatch: direct call to any Yango Tech Retail B2B endpoint — for paths without a dedicated tool (orders/update, receipts/documents/upload, wms/picking/set-state, logistics/delivery/set-state, products-vat/, pricelists/get|create, store-pricelist-links/, 3pl/deliveries/*). Every endpoint of this API is a POST with a JSON body; pass a relative path like "b2b/v1/pricelists/get" and the body object. CAUTION: this tool can perform writes; 5xx/network errors are never retried for it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Each tool targets a distinct resource and action (price lists, orders, order state, events, receipts, stores, products, prices, discounts, stocks). Even similar tools like get_order and get_orders_state are clearly separated by their descriptions, making selection unambiguous.
Tool names follow a consistent pattern: 'query_' for cursor-based feeds, 'get_' for direct retrieval, 'create_', 'set_', 'update_', 'cancel_' for writes, and 'raw_request' as an explicit escape hatch. The verbs are meaningful and consistent, with no mixed conventions.
16 tools is slightly above the typical well-scoped range but appropriate for a comprehensive retail API that spans orders, catalog, pricing, inventory, discounts, and receipts. Each tool serves a distinct purpose, and the count feels justified rather than bloated.
Core workflows are covered with dedicated tools for order creation/cancellation/query, product listing/creation, price get/set, stock query/update, and discount creation. Some operations (e.g., order update, price list creation, product update) lack dedicated tools but are reachable via raw_request, so agents can work around minor gaps.