Skip to main content
Glama

site

This session's cart: add, remove, view, clear

cart

A cart kept for this MCP session (never the store's own cart). add / remove / set a quantity / view / clear; the total is live from the feed. Then checkout_link tells the buyer where to complete the purchase.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qtyNoquantity to add (add, default 1) or to set (set)
actionYes
productNoproduct id or URL (add/remove/set)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose two meaningful traits: the cart is scoped to this MCP session (not the store's persistent cart) and totals are live from the feed. It does not say what clear destroys, whether operations are idempotent, or how errors (e.g. invalid product) are surfaced, which matters for a mutation-capable tool.

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?

Two tight sentences with the scoping constraint (session cart, never the store's cart) front-loaded before the action list and the checkout handoff. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter, no-annotation, no-output-schema tool, the description covers actions and handoff but does not describe what view returns (cart shape, totals per line) or failure behavior. Adequate but leaves an agent guessing about the return surface.

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 67%: qty and product both carry schema descriptions, while action relies on the enum alone. The description adds marginal context by mapping 'set a quantity' to the set action, but adds no detail beyond the schema, so the baseline 3 is appropriate.

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 names the exact resource (a session-scoped cart) and enumerates the full action set (add/remove/set/view/clear), so an agent knows precisely what the tool does. It also explicitly distinguishes itself from the store's own cart, which is the key ambiguity for a shopping MCP.

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 context for the cart's lifecycle and routes the buyer to checkout_link to complete the purchase, which is strong sibling guidance. It stops short of stating when to prefer this over alternatives like product or search for gathering item details.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources