Skip to main content
Glama

create_order

Assemble a basket and get exact prices plus Stripe checkout links. Checkout runs on Stripe's hosted page, completed by whoever holds the payment credentials. Pass dryRun:true to REHEARSE: same validation, same price math, clearly labeled, no order recorded, no links issued, nothing billed — integration-test the full flow risk-free. Item ids — plans: 'pilot', 'desk-private', and 'api' (the Metered API account: your identified key — self-issue one FREE at POST /api/keys, no human in the loop — with billing activated by the desk on this order, usage billed monthly at tariff rates, nothing preset — get_quote prices your exact basket first, get_account shows the live statement); unit: 'watch' (reads of the watched question included); and 'balance' — a BALANCE on your own key, funded once with an amount in USD (min $5, max $500) and drawn down at the flat published Read rate as you ask. Reads are metered per use at the flat tariff rate and are never sold as PREPAID PACKS — a pack is a discounted bundle sized to your guess about how much you will use, and we do not sell one. A BALANCE is a different thing and is sold: the same meter funded in advance, at LIST, no discount, no expiry, no minimum draw, unused balance refundable in full on request. It exists so your principal fills a card form ONCE, ever, instead of once per purchase. Live UNIT prices come from /api/tariff and this description states none of them — the balance band above is a limit on what you may FUND, not a price. Watch topics are SELF-SERVE end to end: pass topics and every one comes back with a checkout link at the published Watch rate — including a topic nobody watches yet, whose price the desk mints on demand with no human in the loop (that one needs your identified key, free and self-issued in one call at POST /api/keys, and arrives in minutes; poll get_order or the statusUrl on the line). The api line still records intent and the desk activates the account. Every line states its own state and what to do next.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoContact email to attach to the order intent (optional)
itemsYesArray of {id, quantity?, amount?} — catalog ids above; `quantity` applies to unit items only, and `amount` (USD, min 5 / max 500) applies to the 'balance' item only and is required on it
dryRunNotrue → rehearse: validate + price the basket, record nothing, issue no links, bill nothing
topicsNoOptional: the quoted topic names (or 1-based topic numbers as strings) this order's Watch lines cover — carried verbatim onto the recorded intent so scoped concerns survive the quote→order handoff. Max 12, each ≤200 chars.
quoteIdNoOptional: the quoteId from get_quote — recorded on the order intent so the desk provisions against that exact quote.
idempotencyKeyNoOptional client key (≤128 chars): makes the orderId deterministic and a retried call return the original intent instead of recording a second one — safe machine retries

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / items / description
      Previous value: -"Array of {id, quantity?} — catalog ids above; quantity applies to unit items only"New value: +"Array of {id, quantity?, amount?} — catalog ids above; `quantity` applies to unit items only, and `amount` (USD, min 5 / max 500) applies to the 'balance' item only and is required on it"
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are present, so the description carries the full burden, and it delivers richly. It discloses side effects of the normal flow (order recorded, links issued, billing activated), explicitly contrasts dryRun (no record, no links, no billing), explains balance funding and refundability, describes the self-serve key issuance, and notes that the api line records intent. It even discloses idempotency behavior (retried calls return original intent). This exceeds typical transparency.

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 but each sentence carries specific, non-redundant information. It front-loads the core purpose and dryRun explanation, then systematically covers item types, pricing, and topics. Some sentences are dense and could be tightened, but the complexity of the tool justifies the length. It does not waste words.

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?

For a tool with 6 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the entire order lifecycle, points to related tools (get_quote, get_account, get_order), and even mentions the statusUrl and polling. It also clarifies edge cases like self-issued keys and no-human-in-the-loop scenarios. Nothing essential for correct invocation is missing.

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?

Even though schema coverage is 100%, the description adds substantial meaning beyond field names: it explains each catalog id ('pilot', 'desk-private', 'api', 'watch', 'balance'), the constraints on `amount` (min $5, max $500), that `quantity` applies only to unit items, and how `topics` are carried verbatim. It also clarifies the difference between funding a balance and buying a prepaid pack. This goes well beyond the baseline.

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 opens with a precise verb and resource: 'Assemble a basket and get exact prices plus Stripe checkout links.' This clearly distinguishes it from siblings like get_quote (pricing only) and get_account (statements), and it internally differentiates the balance item from prepaid packs. The purpose is unambiguous.

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?

The description gives explicit when-to-use and when-not-to-use guidance: it recommends calling get_quote first to price the basket, notes that live prices come from /api/tariff rather than being embedded here, and explains that dryRun:true is the rehearsal mode for integration testing. It also spells out when to use 'balance' instead of 'packs' (packs are explicitly not sold), and when to pass topics. This leaves no ambiguity about alternative tools or conditions.

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