Skip to main content
Glama
Analog-Labs

Firestarter MCP Server

by Analog-Labs

firestarter_approve

Destructive

Confirm and pay for a pending order after buyer approval, using their saved address and selected delivery speed.

Instructions

Confirm and place an order that is awaiting approval — this is the step that actually BUYS and pays. Lifecycle: firestarter_execute (or a listing_id buy) returns options awaiting approval → you confirm the ship-to with the buyer → firestarter_approve places and pays for the order → the buyer can then get a receipt (firestarter_receipt) and follow delivery (firestarter_track_order). The buyer's SAVED DEFAULT address is used automatically — you do NOT need to collect or re-type their street, zip, or phone; just confirm where it's shipping (the execute/approve responses show a masked view). Only pass a delivery_address (or a saved address_id from firestarter_addresses) when the buyer has no saved address or wants THIS order shipped somewhere else. By default it approves the pre-selected (best purchasable) option; pass selected_option or option_id to pick a different one. Delivery speed is the buyer's choice: the option shows a numbered 'Delivery options' menu (Standard / Express / Same-Day with prices + ETAs) — if the buyer wants a faster or specific one, pass shipping_option_index (the [number] from that menu); omit it to use the cheapest. Only Firestarter-purchasable options can be approved — browse-only results (external listings, or Firestarter stores that haven't enabled checkout) are rejected with a view link instead. When the user just says "approve"/"confirm"/"yes" without naming an order, omit execution_id: the tool resolves the single pending purchase automatically (and asks which one only if several are pending). If approval returns PRICE_CHANGED, show the exact updated total to the buyer and ask again; only after they explicitly confirm it, call this tool again with confirm_total set to that exact value AND consent_nonce set to the one-time nonce that PRICE_CHANGED returned (echo it verbatim — it is single-use and cannot be guessed). If no address is saved and none is passed, approval of physical goods is rejected — collect one then.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
option_idNoExact option id (e.g. 'opt_abc123') to approve, as returned in API errors or the execution resource. Takes precedence over selected_option.
address_idNoA saved address id (addr_...) to ship this order to, from firestarter_addresses. Optional — omit to use the buyer's default saved address. Pass only to ship somewhere other than their default.
execution_idNoThe execution ID to approve (e.g. 'exec_abc123'). Omit when the user simply replied "approve": the tool then approves the one execution awaiting approval, surfaces payment-setup guidance if the order is parked awaiting a payment method, or lists the candidates if several are pending.
confirm_totalNoExact updated total in USD from a prior PRICE_CHANGED response. Pass only after showing that total to the buyer and receiving a new explicit confirmation; never guess or pre-fill it on the first approval.
consent_nonceNoThe single-use consent_nonce string from a prior PRICE_CHANGED response. Pass it VERBATIM together with confirm_total when re-approving a price change. It is one-time-use and cannot be guessed — never fabricate it; only echo the exact value the last PRICE_CHANGED returned.
selected_optionNo0-based index into the options list as displayed (the option shown as '1.' is index 0). Omit to approve the pre-selected best option.
delivery_addressNoOptional — pass EITHER a single-line string (e.g. "123 Main St, Austin, TX 78701, US") OR an object { name?, street1, street2?, city, state?, zip?, country? }. The buyer's saved default address is used automatically; only pass a NEW address here to ship this order elsewhere, or when the buyer has no saved address. A partial or odd-shaped address is accepted (never rejected for shape); a complete one (ZIP + state for US/CA/AU) is required only at the pay boundary. On a first order with no saved address, the address you pass is saved as their default for next time.
shipping_option_indexNo0-based index of the delivery speed to use, taken from the numbered 'Delivery options' menu shown for the option (in firestarter_execute / firestarter_status output, or firestarter_shipping_options). Omit to use the cheapest rate; the order total is recalculated server-side for the chosen speed and included in what the buyer approves.
Behavior5/5

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

Discloses far beyond the annotations (destructiveHint=true, readOnlyHint=false): it 'actually BUYS and pays', automatically uses the buyer's saved default address, shows a masked address view, requires a complete address only at the pay boundary, saves a passed address as default, and explains the single-use nonce in PRICE_CHANGED. No contradiction with annotations.

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?

Although long, every sentence earns its place. The description is front-loaded with the core action, then proceeds logically through lifecycle, address handling, option selection, delivery speed, error handling, and re-approval. There is no repetition or fluff; the length reflects the tool's complexity.

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?

Given the tool's complexity, absence of an output schema, and minimal annotations, the description is remarkably complete. It covers the full flow, edge cases (no saved address, PRICE_CHANGED, multiple pending orders, browse-only rejections), and even post-purchase next steps. This is a model description for a high-stakes payment tool.

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 100%, so baseline is 3, but the description adds meaningful context not obvious from parameter names alone: execution_id can be omitted to auto-resolve a single pending purchase, confirm_total and consent_nonce must only be used together after a PRICE_CHANGED, selected_option is 0-based despite the displayed '1.', and shipping_option_index maps to a numbered 'Delivery options' menu. This additional layer justifies above 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 specific verb+resource: 'Confirm and place an order that is awaiting approval — this is the step that actually BUYS and pays.' It clearly distinguishes the tool from siblings by explaining the lifecycle: firestarter_execute returns options, firestarter_approve places the order, and firestarter_receipt/firestarter_track_order follow afterward.

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?

Provides explicit when-to-use and when-not-to-use guidance. It states that browse-only or non-purchasable results are rejected, explains when to omit execution_id, when to pass a delivery_address or address_id, and details the PRICE_CHANGED re-approval flow with confirm_total and consent_nonce. It also names sibling tools (firestarter_execute, firestarter_receipt, firestarter_track_order) to contextualize the workflow.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Analog-Labs/firestarter-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server