Skip to main content
Glama

Ozerki via 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.

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
fulfillmentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / sessionId
      Removed value: -{
-  "description": "Optional. 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).",
-  "type": "string"
-}
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations show readOnlyHint=false, openWorldHint=false, destructiveHint=false, so description carries burden for side effects. It clearly states what the tool does and does NOT do: 'This does NOT create the final Ozerki order and does NOT pay.' It warns about extCart merging with existing basket, that links don't persist store selection, and that available_darkstore lines have varying conditions. No contradictions 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, every sentence earns its place. The description opens with the core purpose, then proceeds through preconditions, steps, warnings, and fallbacks in a logical order. It is front-loaded with the most critical constraint (call only after fulfillment agreed) and ends with strong prohibitions. No filler or repetition.

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?

Despite no output schema, the description explains all return aspects (handoffUrl, fallbackUrl, canHandoff, recoveryOptions, agentNextRu) and covers edge cases like darkstore availability, flat requirement, and link persistence. It also provides recovery instructions and sibling differentiation. An agent has everything needed to call this tool correctly in any supported scenario.

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 description coverage is only 40%, but the description compensates thoroughly. It explains storeId is mandatory for pickup and must come from explicit owner choice, flat is required for delivery with '-' default, goodsId is specifically the Ozerki id not a feed row, and regionId defaults to 14 for Moscow. It also adds meaning to the response fields (canHandoff, recoveryOptions, agentNextRu) which are not in the schema. This goes beyond the bare parameter names.

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 states a specific purpose: 'Ozerki-only availability preflight and tracked basket handoff.' It clearly distinguishes itself from siblings like get_ozerki_pickup_options and list_allowed_stores by explicitly mentioning them and contrasting its behavior. The verb 'prepare' with resource 'handoff' is unambiguous.

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?

Provides explicit when-to-use ('Call only after fulfillment is agreed'), exact steps for pickup (call get_ozerki_pickup_options, present options, obtain choice, pass storeId) and delivery (flat mandatory). Also gives strong when-not guidance: 'Do NOT call list_allowed_stores' and 'Do NOT make the owner rebuild the basket.' It even describes recovery actions when canHandoff=false, leaving no ambiguity.

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

All Ozerki via 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