Skip to main content
Glama

AgentPay

by io.github.zapnikita95
OverviewDiscussionsAdmin

prepare_ozerki_handoff

Ozerki-only availability preflight and tracked basket handoff. Call only after fulfillment is agreed with the owner. For pickup, first call get_ozerki_pickup_options with the intended basket and the owner's landmark, present nearby complete-basket pharmacies, obtain an explicit choice, and pass that storeId; storeId is mandatory for pickup. Never leave pharmacy selection for the owner after handoff. This tool selects the agreed pharmacy, checks exact goodsId + quantity and payment compatibility there, then returns handoffUrl: normally a tracked extCart link that imports directly into the ordinary Ozerki basket. Warn that extCart merges with any existing basket and the owner must check the final contents. If direct import fails, use fallbackUrl, a tracked shared-cart link. Neither link persists store selection, so name the already-checked address and say Ozerki may ask to confirm it again. This does NOT create the final Ozerki order and does NOT pay. If a line status is available_darkstore, handoff can proceed but warn that stock/timing/payment depends on warehouse/address. For delivery, flat is mandatory; if there is no apartment pass flat="-". If canHandoff=false, read recoveryOptions and agentNextRu: preserve available lines, offer another returned pharmacy, lower quantity, change address, or search replacements. Do NOT call list_allowed_stores to find Ozerki pharmacies; that tool lists AgentPay stores, not pharmacy points. Do NOT make the owner rebuild the basket from scratch or invent availability. 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
addressNo
storeIdNoRequired for pickup: store id explicitly chosen by the owner from get_ozerki_pickup_options
regionIdNoOzerki region id, default 14 for Moscow and region
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).
fulfillmentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / allOf
      Added value: +[
+  {
+    "if": {
+      "properties": {
+        "fulfillment": {
+          "const": "pickup"
+        }
+      },
+      "required": [
+        "fulfillment"
+      ]
+    },
+    "then": {
+      "required": [
+        "storeId"
+      ]
+    }
+  }
+]
    • changedInput schema / properties / storeId / description
      Previous value: -"Pickup pharmacy/store id when selected"New value: +"Required for pickup: store id explicitly chosen by the owner from get_ozerki_pickup_options"
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=false, openWorldHint=false, destructiveHint=false), so the description carries the full burden. It discloses side effects (extCart merges with existing basket), limitations (links don't persist store selection, Ozerki may ask to confirm address again), and what is not done (no final order, no payment). It also handles authentication edge cases (sessionId retry) and error paths (canHandoff=false). No contradiction with 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?

The description is long (~300 words) but each sentence carries critical information. It is front-loaded with the core purpose and then details conditions, fallbacks, and prohibitions. While it could be tightened slightly, the density and organization justify the length for such a complex tool.

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?

This tool has no output schema, so the description must cover return values and error handling. It mentions handoffUrl, fallbackUrl, canHandoff, recoveryOptions, and agentNextRu, plus behavior on failure. It also addresses authentication, pickup/delivery branching, and explicit don'ts. For a tool with nested address objects and conditional requirements, nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% per signal, but the description explicitly explains the critical parameters: storeId is mandatory for pickup and must come from owner's choice; flat is required for delivery with '-' fallback; items require real Ozerki goodsId; regionId default is 14; sessionId usage and authentication context. This goes far beyond schema descriptions, adding essential context for correct invocation.

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 a specific verb and resource: 'Ozerki-only availability preflight and tracked basket handoff.' It then explains exactly what the tool does (selects pharmacy, checks items, returns links) and what it does NOT do (create order, pay). It clearly distinguishes from siblings like get_ozerki_pickup_options (prerequisite) and list_allowed_stores (explicitly says not to use it).

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?

It states when to call ('only after fulfillment is agreed'), gives explicit preconditions for pickup (call get_ozerki_pickup_options first, obtain choice, pass storeId) and for delivery (flat mandatory). It names alternatives and conditions (e.g., use recoveryOptions and agentNextRu on failure, never call list_allowed_stores, never make the owner rebuild basket). This is comprehensive and unambiguous.

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