Skip to main content
Glama

Order from a verified business

place_order
Destructive

Order an item a verified business publishes (see list_business_offerings or find_businesses). Two steps. First call without confirm: it places nothing and returns the seller, the item, the quantity, the unit price, the full total, the currency, how payment happens, and the refund and cancelling terms. Show those to the customer. Then call again with the same fields and confirm: true, only after the customer agreed. The order goes straight to the business, where it already works: email, its own store or its own system, and the answer carries a reference to pass to get_order_status. When the business connected a payment account (Stripe, PayPal, Mollie, Razorpay, Lemon Squeezy or Paddle), the answer carries a pay_url on that account; the money goes to the business, never to Orbylon. For an appointment, the answer can carry a book_url where the buyer chooses the time on the business's own booking page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>",
      "fulfilment": "<fulfilment>"
    },
    "name": "place_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemNoThe item name exactly as listed
noteNo
domainYesThe business domain, e.g. example.com
confirmNoLeave out to see the seller, the full price and the terms first. Send true only after the customer agreed to them.
item_idNoThe item id from the catalogue
quantityNo
fulfilmentYesHow the buyer receives it, and how the business reaches them
idempotency_keyNoSend the same key when retrying

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / confirm
      Added value: +{
      +  "description": "Leave out to see the seller, the full price and the terms first. Send true only after the customer agreed to them.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag it as destructive, non-idempotent and open-world, but the description adds substantial context beyond them: the preview/confirm safety contract, the exact data returned in preview (seller, unit price, total, currency, refund/cancel terms), where the order is routed, that money flows to the business and never to Orbylon, the set of connected payment providers, and the book_url appointment path. This is rich behavioral disclosure that goes well past the annotations.

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?

Front-loaded correctly: purpose and the two-step flow come first, then routing/payment details. It is dense and contains some run-on sentences (e.g. 'The order goes straight to the business, where it already works: email...'), but nearly every sentence carries actionable information, so little could be cut.

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 destructive, open-world mutation with no output schema, the description is complete enough to call correctly: it covers the mandatory consent flow, the preview return fields, the final-call return fields (reference for get_order_status, pay_url, book_url), and the payment routing. Nothing essential is missing.

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 coverage is 75% and the schema already documents domain, item, item_id, confirm and idempotency_key. The description reinforces the crucial semantics of 'confirm' (re-send same fields, only after agreement) and explains what the non-confirm call returns, which clarifies the required fields. It adds some value but does not compensate for undocumented params like quantity, note, and nested fulfilment fields beyond the object-level description.

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?

States a specific verb+resource ('Order an item a verified business publishes') and immediately routes the agent to the sibling discovery tools (list_business_offerings, find_businesses) for finding items. An agent can tell this apart from request_quote, get_order_status, and the lookup tools without opening any schema.

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 defines the two-step protocol: first call without 'confirm' placed nothing and previews terms, then a second call with the same fields plus confirm:true only after the customer agreed. This gives unambiguous when-to-use and when-not-to-use (never confirm unprompted) guidance plus the discovery alternatives.

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