Skip to main content
Glama

get_checkout

Retrieve checkout for selected cart items, showing payment methods, delivery options, shipment details, and totals. If unavailable, it identifies the issue, such as missing item selection.

Instructions

The order being formed from the selected cart items, with everything that can be changed: payment methods (each with its payment_type), the pay-on-delivery switch, one entry per destination in deliveries (each with its shipments in split_keys and its selectable pickup_points), the shipments with their delivery dates, points choices and the money breakdown — totals.total is what Ozon charges today (0 ₽ on a fully deferred order) and totals.order_total is what the order costs.

Pay-on-delivery does not always cover the whole order. pay_after_receipt .scope is one of "full", "partial" (some items must be paid up front: prepayment_amount now, post_payment_amount on receipt) or "none", and .note states it in words. On a partial order pay_now_items and pay_on_receipt_items name the lines on each side, as Ozon itself splits them, and the shipments are loaded with their items, each carrying prepaid (null when it holds items from both sides). shipment_items forces that loading on (true) or off (false); by default it happens only when scope is "partial".

Forms the checkout itself if Ozon has not yet. If it reports available=false, reason says what to fix — usually: select cart items. Change it with configure_checkout, submit with place_order.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shipment_itemsNoForce loading each shipment's items on (true) or off (false); default loads them only when the order is split between prepaid and deferred parts.

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 behavioral disclosure. It reveals a side effect ('Forms the checkout itself if Ozon has not yet'), explains the available=false reason mechanism, details the shipment_items loading default, and describes nuanced pay-on-delivery scope behavior. This is unusually transparent.

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 nearly every sentence contributes distinct information about checkout structure, behavior, or default values. It is not front-loaded with a clear verb phrase, but it is well organized and avoids redundancy.

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?

Given the output schema exists, the description appropriately focuses on behavioral semantics and edge cases rather than return fields. It covers the tool's side effect, failure reasons, parameter defaults, and relationship to sibling tools, making it complete for an agent deciding to call or interpret this tool.

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?

The single parameter shipment_items has full schema description coverage, so the baseline is 3. The description adds context by tying the default loading behavior to pay_after_receipt.scope being 'partial' and explaining that shipment_items forces loading on or off. This enriches the parameter's meaning beyond the schema alone.

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 precisely defines what get_checkout returns: the current checkout being formed from selected cart items, including payment methods, deliveries, shipments, and totals. It also distinguishes the tool from its direct siblings by stating that configure_checkout changes the checkout and place_order submits it.

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?

The description provides clear context: it operates on selected cart items, can create the checkout if Ozon has not yet, and reports available=false with a reason when something needs fixing. It names the alternatives configure_checkout and place_order, but does not explicitly state scenarios where get_checkout should be avoided in favor of get_cart or other tools.

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