Skip to main content
Glama

AgentPay

by io.github.zapnikita95
OverviewDiscussionsAdmin

prepare_dixy_checkout

Dixy-only checkout preparation. Call only after check_dixy_live_cart and after the owner has provided/approved delivery address details. Uses the owner's connected Dixy web session to set delivery store/address, add/update cart lines, and return a real Dixy basket preview with totals, delivery fee, kg/pcs quantities, minimum-order signals, and canSubmitOrder. Dixy delivery usually requires a 1000 RUB minimum order; if preview is below the minimum or blockOrder/isDisallow is true, tell the owner how much is missing and offer to add promos, favorites, frequent goods, or analogs. If the response errors with DIXY_CART_NOT_EMPTY, ask the owner whether to clear the existing Dixy basket; retry with clearExistingCart:true only after explicit approval. If order creation later returns action=showAuth / DIXY_REAUTH_REQUIRED, use the fresh openUrl and linkSessionId included in that same error; call start_dixy_call_auth(forceNew:true) only if the recovery link is absent. Never ask for a phone number in chat. Poll after the owner completes the page, then retry checkout. If order creation returns DIXY_ANTIBOT_REQUIRED, explain plainly that Dixy showed a «Я не робот» check on server-side checkout, so AgentPay needs a user-side browser handoff or official partner checkout API/whitelist; do not claim an order/payment URL exists. Do not mention cookies/PHPSESSID to the owner. This does not create a Dixy order and does not pay. Show the returned preview to the owner; final order creation must go through AgentPay's explicit confirmation flow, not directly through MCP. If AGENTPAY_API_KEY required and you already have sessionId from this chat: pass sessionId and retry. Never begin_agent_link again. Never ask the owner to edit connector settings or reconnect. Never web-search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
deliveryYes
promocodeNo
sessionIdNoOptional. Agent-link sessionId from begin_agent_link / poll_agent_link. Pass on every tool when connector has no Authorization Bearer (Grok/ChatGPT/Claude). After status=approved this authenticates as als_<sessionId>. Never invent a sessionId. Never ask the owner to open Authorization settings (Grok has none).
fulfillmentNoSame receiving mode confirmed in live-cart. Defaults to delivery; for pickup delivery.address must be the demo storeAddress.
dixySessionIdNopartner_session_id returned by poll_dixy_call_auth. This is the opaque Dixy session.
clearExistingCartNoSet true only after the owner explicitly approved clearing the existing Dixy basket

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / fulfillment
      Added value: +{
+  "description": "Same receiving mode confirmed in live-cart. Defaults to delivery; for pickup delivery.address must be the demo storeAddress.",
+  "enum": [
+    "delivery",
+    "pickup"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / dixySessionId
      Added value: +{
+  "description": "partner_session_id returned by poll_dixy_call_auth. This is the opaque Dixy session.",
+  "type": "string"
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only state readOnlyHint=false, openWorldHint=false, destructiveHint=false. The description goes far beyond these: it discloses side effects ('This does not create a Dixy order and does not pay'), mutation of the cart, the 1000 RUB minimum-order behavior, the DIXY_CART_NOT_EMPTY clearing flow, reauth steps, anti-bot handling, and communication constraints (never ask for phone number, don't mention cookies). This is rich behavioral disclosure well beyond what annotations provide.

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 description is long and dense, but it front-loads the core purpose and prerequisite before moving to conditional scenarios. Each sentence carries operational meaning, from minimum-order handling to error recovery to security constraints. It could be more scannable with lists or subheadings, but for a tool with this many edge cases the length is mostly earned.

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?

There is no output schema, yet the description explicitly names the return fields (totals, delivery fee, kg/pcs quantities, minimum-order signals, canSubmitOrder). It also covers all the major runtime scenarios an agent could hit: minimum order, cart not empty, reauth, anti-bot, missing API key, and session handling. For a complex checkout tool with no output schema, this is complete enough to call 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 parameter descriptions cover about 57% of parameters, so the description adds value by explaining operational semantics: 'kg/pcs quantities' maps to item quantity types, 'clearExistingCart:true only after explicit approval' clarifies a boolean parameter's triggering condition, and 'sessionId from this chat' clarifies session reuse. It doesn't systematically redocument every parameter, but the overlap is partially compensated by the schema's own descriptions plus these contextual additions.

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 opens with 'Dixy-only checkout preparation', naming a specific verb ('prepare'), a specific resource ('Dixy checkout'), and a scope that distinguishes it from Ozerki and other checkout flows. It then states concrete responsibilities: setting delivery store/address, adding/updating cart lines, and returning a basket preview with totals, delivery fee, quantities, minimum-order signals, and canSubmitOrder. This clearly differentiates it from siblings like check_dixy_live_cart and prepare_ozerki_handoff.

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?

Usage is explicitly gated: 'Call only after check_dixy_live_cart and after the owner has provided/approved delivery address details.' It also routes error handling to specific siblings ('call start_dixy_call_auth(forceNew:true) only if the recovery link is absent') and warns against incorrect flows ('Never begin_agent_link again', 'Never ask the owner to edit connector settings or reconnect'). This is clear when-to-use and when-not-to-use guidance with named alternatives.

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

All AgentPay toolsInspect
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