Skip to main content
Glama
ztemerbekov

A1 Yandex KIT MCP

by ztemerbekov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get customer cart

get_customer_cart
Read-only

Retrieve a customer's current cart, including items, quantities, prices, totals, and updated_at, to analyze abandoned carts and distinguish empty carts from customers who never had one.

Instructions

Get the current cart of a customer — the source for abandoned-cart work: items with quantity and per-unit/line prices, plus total_price (before discounts) and total_final_price (after item and bundle discounts). An empty cart, and a customer who never had one, both return items: [] with zero totals; updated_at is absent in the never-had-one case and is the only way to tell the two apart — there is no abandoned-cart flag, so decide staleness from updated_at yourself. product_variant_id is NOT a unique key for a line: the same variant appears in several items when it is part of a bundle, was added with different addons, or was picked as a gift. quantity is what the buyer put in and may exceed stock — the API clamps it only when they reopen the cart or check out. Items whose variant was unpublished are dropped from the response. A cart promocode is NOT reflected in total_final_price (unlike Order.total_final_price), so cart totals are not a forecast of the order total.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesCustomer ID (UUID).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.0

TDQS

A4.4/5.0
Behavior5/5

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

With only readOnlyHint=true in annotations, the description carries rich behavioral detail beyond safety: it explains empty vs never-had-one carts, the non-uniqueness of product_variant_id, quantity possibly exceeding stock, dropped unpublished variants, and that promocodes are not reflected in total_final_price. This is exceptional disclosure.

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 purpose is front-loaded, and each subsequent sentence adds distinct, non-redundant information about return shape and edge cases. The single dense paragraph is slightly demanding but justified by the lack of an output schema.

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?

With no output schema and only one annotation, the description thoroughly explains the return structure, edge cases, and behavioral quirks an agent needs to correctly interpret the tool's output. Nothing critical is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the single parameter (id) is fully documented in the schema. The description adds no parameter-level meaning, so the baseline of 3 applies.

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?

States a specific verb and resource ('Get the current cart of a customer') and immediately frames it as the source for abandoned-cart work, which distinguishes it from sibling tools like get_customer_orders or order-level tools.

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?

Provides clear usage context by identifying the abandoned-cart use case and explaining that staleness must be inferred from updated_at. However, it names no explicit alternative tool for related questions (e.g., orders) and gives no when-not guidance, so it falls short of a full 5.

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

Deploy Server

Other Tools