Skip to main content
Glama
Analog-Labs

Firestarter MCP Server

by Analog-Labs

firestarter_execute

Start a purchase by finding products from a natural-language request, verifying sellers, and quoting shipping. Returns ranked options awaiting approval — no payment until approved.

Instructions

Start a purchase. Step 1 of the buy flow: it finds products matching a natural-language request (or pins to an exact listing), verifies the seller, computes real pricing + shipping, and returns ranked OPTIONS that are AWAITING APPROVAL — it does NOT pay yet. Full flow: firestarter_execute (find/price) → firestarter_approve (confirm + pay) → firestarter_receipt (proof of payment) and firestarter_track_order (delivery). Each purchasable option lists real DELIVERY OPTIONS (Standard / Express / Same-Day with prices and ETAs); the delivery speed is the buyer's choice, selected at approval via shipping_option_index (firestarter_shipping_options re-fetches or previews a speed's total; firestarter_shipping_estimate quotes shipping on a listing BEFORE any purchase starts). No budget, address, or payment method is needed to call this — a card is requested only at the very end, after the buyer approves; browsing, quoting, and comparing shipping never require one. A saved shipping address is used automatically — the buyer's street, zip, and phone are already on file, and the response's default_delivery shows a masked view of the ship-to. A new address matters only when none is saved or the order ships somewhere else; a saved address_id (from firestarter_addresses) is accepted in place of a re-typed address. When the buyer's location (country, and city if known) is provided, results are localized to their country so a buyer in Kenya sees locally-deliverable options first instead of an empty or US-only list. An exact listing id (lst_..., e.g. from a firestarter.network/l/ share link or firestarter_catalog_search) can be passed as listing_id to skip search and pin to that exact product. Results may include browse-only options (external, or not buyable right now) that can't be approved — each carries a link that can be shared instead. auto_pay presumes the buyer's explicit prior authorization to buy without a confirmation step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYesNatural language description of what to buy (e.g. 'specialty coffee beans under $30'). This is the only required field — call with just this and refine later.
auto_payNoIf true, automatically pay for the best option within budget WITHOUT a confirmation step — only when the buyer explicitly pre-authorized it. If false (default), options are returned for approval.
locationNoWhere the buyer is. Pass this whenever you know it (from the conversation, profile, or a prior message) even without a full delivery address — it makes search location-aware so local marketplaces are shown first.
priorityNoOptimization priority: cost (cheapest), speed (fastest delivery), quality (best rated). Default cost — shipping is quoted and shipped at the cheapest carrier rate unless the buyer asks for speed/quality.
address_idNoA saved address id (addr_...) to ship to, from firestarter_addresses. Optional — omit to use the buyer's default saved address. Localizes search + shipping to that destination.
budget_maxNoMaximum budget in USD. Optional — omit to see all options regardless of price.
listing_idNoExact Firestarter listing id (lst_...) to buy — from a listing or a share link (firestarter.network/l/<id>). Pins the purchase to that listing, skipping product search. Always pass it when you have one.
requested_byNoWho asked for this purchase, when relaying someone else's request (e.g. a teammate in chat). Stored as execution metadata so the buyer's dashboard can attribute the order. Integrations set this programmatically; pass it whenever you know the requester.
voucher_codeNoA discount code the buyer already has (voucher / coupon / promo code). Only meaningful for a code the buyer supplied — the best publicly available voucher is applied automatically, so searching for codes is unnecessary; this field exists for private or targeted codes that auto-apply cannot find. If the code can't be used the order still proceeds at the best price available, and the response explains why it didn't apply.
hold_at_shippedNoTEST MODE ONLY (fs_test_ keys): park the order at 'shipped' instead of auto-delivering it ~2s later. The mock shipment, tracking number and 'shipped' status all still happen; only the auto-deliver timer is skipped, so the order can be inspected mid-flight and then delivered explicitly with firestarter_confirm_delivery. Ignored on a live key. Use it to stage a shipped-but-not-delivered order for QA.
delivery_addressNoOptional shipping address — 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? } (country is an ISO code, e.g. US/TH; defaults to US). The buyer's saved default address is used automatically at approval, so only pass one here if they have none saved or want it shipped elsewhere; prefer a saved address_id. A COMPLETE address (ZIP + state for US/CA/AU) lets execute quote a REAL carrier rate up front instead of the flat placeholder; a partial or odd-shaped address is accepted anyway (never rejected for shape) and the response's `needs_more` names exactly what to collect.
hold_at_deliveredNoKeep the escrow hold in place after delivery, instead of releasing it the moment the order is marked delivered, so the order can still be disputed — which is what firestarter_disputes needs to open a dispute at all. The order still ships and delivers normally; only the payout is held, on the same inspection window a live order gets. REQUIRES the organization's test mode to be ON as well as a test key: a test key on its own runs the mock sandbox, which never creates an escrow hold for this to act on, and the API now refuses the flag there (HOLD_AT_DELIVERED_UNAVAILABLE) rather than accepting a purchase whose hold would be silently dropped. Inert on a live key, where escrow already holds for the full window.
Behavior5/5

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

Annotations only convey readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds crucial behavioral context beyond those: the tool stages options for approval without charging, browse-only options cannot be approved, auto_pay requires explicit prior authorization, a saved address is silently reused, and test-mode hold flags have specific sandbox semantics. No contradiction with annotations exists.

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 front-loaded with the most important facts — Step 1, no payment yet, and the full flow — and is organized in a logical progression from purchase flow to shipping, addresses, localization, listing pinning, and special modes. It is long, but the complexity of the tool and absence of an output schema justify most of the length; a small amount of overlap with parameter descriptions keeps it from a perfect score.

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?

With no output schema, the description carries the full burden of explaining what the agent should expect, and it does so thoroughly: ranked options, delivery options, masked default_delivery, needs_more fields, browse-only options, and the buy-flow sequence. It also covers edge cases like no saved address, wrong-country results, listing_id pinning, auto_pay pre-authorization, and test-only hold flags, making it highly complete for an agent selecting and invoking this tool.

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?

Although schema coverage is 100%, the description meaningfully extends the schema: it explains that `request` alone is sufficient and can be refined later, that `location` should be passed whenever known for localized results, that `listing_id` should always be passed when available, and that `voucher_code` is only for private or targeted codes. It also clarifies delivery_address shape trade-offs and test-mode hold behavior beyond the raw schema text.

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 'Start a purchase. Step 1 of the buy flow' and precisely defines what the tool does: find matching products, verify the seller, compute pricing and shipping, and return ranked options awaiting approval — while explicitly stating it does NOT pay yet. It also names the full flow and contrasting sibling tools, so there is no ambiguity against firestarter_approve, firestarter_receipt, or firestarter_track_order.

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 guidance: this is the first step of purchasing, while approval/payment belongs to firestarter_approve, proof to firestarter_receipt, and tracking to firestarter_track_order. It also clarifies that shipping quoting and comparison happen via firestarter_shipping_options/firestarter_shipping_estimate before a purchase starts, and that no card is needed until after approval.

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