Skip to main content
Glama

Synchronity

by io.github.themewireco

quick_checkout

Assemble checkout-ready cart(s) in ONE call for a multi-product (and optionally multi-store) request. Creates a cart per store, adds all items, and sets the shipping address — then returns the cart(s) with delivery options to choose. Use this when the buyer lists several products at once (optionally across stores) and/or gives their address up front, instead of calling create_cart/add_to_cart/set_shipping_address separately. Does NOT select delivery, check out, or pay — the buyer picks delivery (select_shipping_option) and approves checkout/payment per store afterward. Out-of-stock items are reported; pass customer.email to auto-arm a back-in-stock alert for them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesProducts to buy. Each entry: { site_id, product_id, quantity, variant_id?, addons? }. Items may span multiple stores (grouped by site_id).
customerNoOptional buyer contact carried for checkout; customer.email arms back-in-stock alerts for out-of-stock items.
shipping_addressYesBuyer delivery address (applied to every store).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds that it creates carts per store, reports out-of-stock items, and can auto-arm back-in-stock alerts via customer.email, providing full behavioral context.

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?

The description is well-structured, starting with the main purpose, then usage guidance, exclusions, and additional details. Every sentence adds value without 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 tool's complexity (multi-store, nested objects), the presence of an output schema, and rich annotations, the description fully covers the behavior, use cases, and limitations, leaving no gaps.

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?

With 100% schema coverage, the description adds value by explaining the items array structure, that shipping_address applies to every store, and that customer.email triggers back-in-stock alerts, going beyond the schema's basic definitions.

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 clearly states the tool assembles checkout-ready carts in one call for multi-product and optionally multi-store requests, distinguishing it from separate calls like create_cart, add_to_cart, and set_shipping_address.

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?

Explicitly says to use this when a buyer lists several products at once or provides an address upfront, and lists what it does not do (select delivery, check out, pay), directing to select_shipping_option and execute_checkout.

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

All Synchronity toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct action or resource, with detailed descriptions that clearly differentiate cart management, checkout flow, payment steps, delegation, orders, and product operations. Potential overlaps like get_active_cart vs. get_cart are resolved by their specific use cases.

Naming Consistency5/5

All tools use a consistent verb_noun_snake_case pattern (e.g., add_to_cart, set_shipping_address). There are no mixing of conventions like camelCase or inconsistent verb styles.

Tool Count4/5

26 tools is on the higher side but appropriate for a comprehensive e-commerce server covering product discovery, cart management, checkout, payment, orders, and reviews. Could potentially be streamlined slightly, but still reasonable.

Completeness5/5

The tool set covers the full e-commerce lifecycle: site listing, product search/compare/reviews, cart CRUD, coupon application, shipping, checkout, payment with delegation and OTP, order retrieval, and back-in-stock alerts. No obvious gaps for typical buyer workflows.

Resources