Latchbell

Pay for an order

checkout_order

Like request_order, but the customer pays now. Only when products or catalog show payments.online true and the estimate has fixed prices. Same inputs, after the customer approves the itemized total. With shared_payment_token (a Stripe token you issued to payments.agent_pay.network_business_profile for this total in usd) it charges at once: payment_status paid, requires_action for a card check, or an error (retry with a new token and the same request_key). Without one it returns checkout_url for the customer to pay on Stripe. Never ask for or pass card numbers. The money goes to the business; it confirms timing in the conversation. No stock hold.

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": {
      "business": "<business>",
      "lines": "<lines>",
      "customer_name": "<customer_name>",
      "fulfillment": "<fulfillment>",
      "catalog_revision": "<catalog_revision>",
      "expected_estimate_cents": "<expected_estimate_cents>",
      "customer_authorized": "<customer_authorized>",
      "request_key": "<request_key>"
    },
    "name": "checkout_order"
  }
}

Input Schema

Name	Required	Description
`zip`	No	Delivery ZIP (delivery only)
`note`	No
`lines`	Yes
`address`	No	Delivery address (delivery only)
`business`	Yes
`fulfillment`	Yes
`request_key`	Yes
`customer_name`	Yes
`preferred_time`	No
`catalog_revision`	Yes
`customer_authorized`	Yes
`shared_payment_token`	No	Stripe shared payment token (spt_…) issued to agent_pay.network_business_profile for this total
`expected_estimate_cents`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only flag it as non-read-only and open-world; the description adds far more: the three possible outcomes of a tokenized charge (paid, requires_action, error), the retry semantics with the same request_key, the checkout_url fallback, the prohibition on card numbers, and the explicit 'No stock hold' caveat. That is exactly the behavioral context an agent needs before invoking a payment.

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?

Dense but front-loaded: eligibility first, then the two payment paths, then safety and caveats. Sentences are short and each carries information, though the run-on sentence about tokenized outcomes packs three branches into one line.

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?

For a 13-parameter, no-output-schema payment tool, the description covers eligibility, both invocation modes, failure handling, and the stock-hold caveat. Gaps remain around expected_estimate_cents purpose and fulfillment prerequisites (zip/address), but the core decision-relevant behavior is present.

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 low (23%), so the description must compensate, and it explains the crucial shared_payment_token (a Stripe spt_ issued for this total in usd), the meaning of request_key for retries, and customer_authorized implicitly via 'after the customer approves the itemized total'. Many of the 13 parameters (catalog_revision, expected_estimate_cents, lines structure) are left to the schema.

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 and resource ('the customer pays now' for an order) and explicitly distinguishes it from the sibling request_order ('Like request_order, but the customer pays now'). An agent can tell immediately which of the two ordering tools to pick.

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?

Gives concrete preconditions: products/catalog must show payments.online true, the estimate must have fixed prices, and the customer must approve the itemized total. It also branches on shared_payment_token presence. It does not name what to do if payments.online is false beyond implied use of request_order, so it falls short of a full 5.

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

All Latchbell tools Inspect

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

Need Help?