Skip to main content
Glama

configure_checkout

Set one or more checkout options—payment, pickup point, pay-on-receipt, or points—and get the recalculated order. Omitted options stay unchanged.

Instructions

Set checkout options and return the recomputed order — one call can set several. Omit an argument to leave that option alone. Every value comes from a get_checkout() answer, so read that first; passing something Ozon does not offer is refused with the list of what it does. Applied in the order Ozon recalculates them: destination, payment, pay-on-delivery, points. Turning points on can withdraw the pay-on-delivery offer, so check the result rather than assuming.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pointsNoHow many Ozon points to spend; 0 spends none. Offered amounts are in points[].
paymentNoA payment method: a word ("СБП", "Ozon Карта", "новой картой"), a masked card ("**5898") or a payment_type id. Must be one get_checkout() offers.
split_keyNoWhich shipment to retarget, from deliveries[].split_keys. Only needed when the order has more than one destination — otherwise the choice is unambiguous.
pickup_pointNoWhere to deliver: the point number ("№1449460"), part of its address ("Данилова") or its address_book_id. Must be one of deliveries[].pickup_points with available=true.
pay_after_receiptNoTurn «Оплатить после получения» on or off. Only when pay_after_receipt.available.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pointsNo
reasonNo
totalsNo
availableNo
shipmentsNo
deliveriesNo
installmentNo
payment_optionsNo
pay_after_receiptNo
place_order_actionNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.2.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries full burden, and it delivers: it discloses validation behavior (refusal with list), the order of application, and a side-effect (points can withdraw pay-on-delivery). This is rich behavioral context beyond what any annotation would 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 dense but each sentence earns its place: purpose, prerequisite, error behavior, ordering, and a warning. It is front-loaded with the core purpose. Slightly longer than minimal, but no wasted words.

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?

For a mutation tool with 5 parameters, it covers prerequisites, error handling, application order, and a side-effect warning. An output schema exists, so return format is covered. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter dependency (points affecting pay-on-delivery) and the 'omit to leave unchanged' semantics, which are not captured in the individual schema descriptions. This adds meaningful value beyond the schema.

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 verb ('Set'), a resource ('checkout options'), and the key behavior ('return the recomputed order'), and it distinguishes itself from siblings like get_checkout and place_order. It clearly communicates the scope in the first sentence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs the agent to read get_checkout() first and warns that invalid values are refused, which is a strong usage directive. It implies the alternative (use get_checkout for reading) but does not name it explicitly, so it falls just short of a 5.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Alexander-Zhukov/ozon-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server