Skip to main content
Glama
Sign In

Versum Agent Assistant

by io.github.sudzikcoin
OverviewDiscussionsAdmin

What an order would cost delivered to an address — asked of the shop’s own cart, nothing ordered

quote_order
Idempotent

Free. For a business on WooCommerce or Shopify (its card says platform), with no owner connection: puts the offering in a cart session of OUR OWN on the shop’s public cart, gives it the delivery address and reads back what the shop itself computes — delivery.state confirmed | refuted | unknown for that address, options (each delivery / pickup with its price, tax and the whole order’s total), tax, total, currency, and delivery_date ONLY when the shop publishes one in its standard fields (otherwise unknown — ask the shop). Nothing is ordered, the cart is emptied afterwards, and only the address is sent (no name, e-mail or phone; nothing is stored). Shopify’s public cart has no tax: tax.state is unknown and the total is before tax. A shop whose cart is closed answers not_available with the reason; so does any other platform. When the shop needs more of the address than you gave, status: needs_address names the missing fields. A required add-on the page asks for («a card with a message?») is answered «no» unless you pass options; options_used says what was chosen. Hand order_url to the user to buy.

Input Schema

NameRequiredDescriptionDefault
itemsNoseveral different items of the SAME shop in one cart (delivery and tax on the whole order); offering_id is then the first of them
optionsNoanswers to the product page’s own add-on questions; the rest are answered «no»
quantityNodefault 1
deliver_toYeswhere it must be brought: "33139", "Miami Beach, FL 33139", or {postcode, state, city, address_1}
variant_idNoa variant id from the card when it lists several
offering_idYesthe offering id from a card

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With annotations already present, the description adds substantial behavioral context: it creates a temporary cart session of its own, empties the cart afterwards, sends only the address, stores nothing, and reports specific failure states such as `not_available` and `needs_address`. It also discloses platform-specific tax limitations for Shopify and the add-on defaulting behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The content is mostly relevant and front-loads key constraints, but it is delivered as a dense paragraph with many clauses and parentheticals. Structuring the platform constraints, side effects, and return states separately would make it easier to scan.

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?

There is no output schema, so the description carries the full burden of explaining returns, and it does: it documents `delivery.state`, `options`, `tax`, `total`, `currency`, `delivery_date`, `status: needs_address` with `missing`, and `options_used`. It also explains failure responses such as `not_available`, making it complete for an agent to call and interpret results.

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 description coverage is 100%, so the baseline is 3. The description still adds meaning about `options` answering the product page's add-on questions, defaulting unanswered add-ons to 'no', and `options_used` reporting what was chosen; it also clarifies that `deliver_to` sends only the address.

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 a specific purpose: obtaining a delivered price quote from the shop's own cart without placing an order. It distinguishes itself from ordering by saying 'Nothing is ordered' and directing the user to `order_url` to buy, which separates it from `place_order`.

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 gives clear applicability conditions: free, for WooCommerce or Shopify businesses with no owner connection, and notes that closed carts or other platforms return `not_available`. It does not explicitly name sibling alternatives like `check_availability` or `place_order`, but its 'nothing ordered' and 'hand `order_url` to the user to buy' guidance provides practical routing.

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

All Versum Agent Assistant 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