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: 'analyst', 'power', '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). Reads are metered per use at the flat tariff rate, never sold as prepaid packs. Live prices come from /api/tariff; this description states none. 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?} — catalog ids above; quantity applies to unit items only
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

TDQS

A4.4/5.0
Behavior5/5

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

No annotations are present, so the description fully owns behavioral disclosure. It covers external Stripe-hosted checkout, dry-run side effects (no order, no links, no billing), billing mechanics for the API plan, self-served watch topics, and the fact that topics can be minted on demand. This goes far beyond a simple 'create an order' statement.

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 description is information-dense but also a long single paragraph with run-on structures and digressions like tariff note and key issuance details. It is not well structured or easily scannable; with more forbidding, the same depth could be delivered more concisely.

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

Completeness4/5

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

The description covers main operational behavior, catalog specifics, dryRun, watcher topics, and what type. However, with no output schema, the exact response shape—orderId, checkout links, line-level statuses—is only hinted at via 'every line states its own state' and 'statusUrl on the line'. More explicit return-value clarification would make it fully outward factor.

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 covers 100% of parameters, but the description adds important catalog semantics not present in the schema: plan identifiers, the watch/read unit, the Metered API key flow, and the fact that reads are never prepaid. That added meaning helps the agent determine valid item ids and shape the items array correctly.

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 frames create_order as the tool for assembling a basket into an order with exact prices and Stripe checkout links, and differentiates it from get_quote by noting quote flow and from get_order by mentioning polling order status. The wording 'no order recorded' for dryRun confirms the normal path records an order, so the intended resource 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete guidance on when to use dryRun for rehearsal versus a real transaction, and points to get_quote for pre-pricing and get_order/statusUrl for post-order status. It does not explicitly state 'use get_quote instead when you only need pricing,' but the relationship is clear enough.

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.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct function: ask is async event queries, get_answer retrieves results, get_signals and top_accelerating provide different signal views, get_entity and search_entities cover entity details and search, etc. No two tools have overlapping purposes, and descriptions clearly separate them.

Naming Consistency4/5

The majority of tools follow a 'get_' prefix for retrieval (13 of 21) and other clear verbs like 'ask', 'create_order', 'propose_topic', 'send_feedback'. A few use noun phrases like 'todays_brief' and 'top_accelerating', which breaks the pattern slightly but are still intuitive. Overall consistent and predictable.

Tool Count5/5

21 tools cover the full scope of the server: exploration, querying, ordering, account management, feedback, and data records. Each tool serves a clear purpose without redundancy, and the count feels well-scoped for the domain.

Completeness4/5

The tool surface covers all major workflows: browsing signals, asking questions, getting detailed reports, ordering, providing feedback, and proposing new topics. Minor gaps exist (e.g., no explicit tool to cancel an order or manage watched topics directly), but core operations are present and agents can handle the domain effectively.

Resources