Skip to main content
Glama
Analog-Labs

Firestarter MCP Server

by Analog-Labs

firestarter_execute

Find and price products for purchase: search by natural language or exact listing, verify seller, calculate real shipping, and return ranked options awaiting approval before payment.

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) → review options with the buyer → 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) — present these to the buyer so they can pick a speed, don't silently assume the cheapest; the buyer chooses at approval via shipping_option_index (use firestarter_shipping_options to re-fetch or preview a speed's total; for a shipping quote on a listing BEFORE starting any purchase, use firestarter_shipping_estimate). You do NOT need a budget, an address, or a payment method to call this — a card is only requested at the very end, after the buyer approves; browsing, quoting, and comparing shipping never require one. If the buyer has a saved shipping address, it is used automatically — you do NOT need to ask for their street, zip, or phone; the response's default_delivery shows a masked view of it so you can just confirm ("ship to your saved address?"). Only collect a new address if they have none saved or want it shipped somewhere else, and prefer passing a saved address_id (from firestarter_addresses) over re-typing it. ALWAYS pass the buyer's location (country, and city if known) when you know it — results are localized to their country so a buyer in Kenya sees locally-deliverable options first instead of an empty or US-only list. When you already have an exact listing id (lst_..., e.g. from a firestarter.network/l/ share link or firestarter_catalog_search), pass listing_id to skip search and pin to that exact product. Results may include browse-only options (external or checkout-not-enabled) that can't be approved — share their links instead. Set auto_pay only when the buyer has explicitly pre-authorized buying 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). Pass it ONLY when the buyer gave you one — you do NOT need to hunt for codes, since the best publicly available voucher is applied automatically. Use this for a private or targeted code, which 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 so you can tell the buyer.
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.
Behavior5/5

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

Annotations only provide readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description carries the transparency burden. It discloses that no payment occurs at this step, a card is only requested at approval, auto_pay bypasses confirmation, saved addresses are auto-used, browse-only options can't be approved, and partial addresses yield a needs_more field. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded with purpose and flows well across topics. While most sentences earn their place, there is minor repetition (e.g., a card not being needed is stated twice) and some passages could be tightened without losing clarity. Still, given 10 parameters and complex workflow, the length is mostly justified.

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 compensates by describing key response elements (ranked options, delivery options, default_delivery, needs_more), covers edge cases (browse-only, partial address, no saved address), and situates the tool within the full purchase flow with sibling names. It is exceptionally complete for a tool of this complexity.

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?

Despite 100% schema coverage, the description adds significant layering: request is the only required field and can be refined later; location should always be passed when known; address_id is preferred over delivery_address; delivery_address shape affects real carrier rate quoting; voucher_code should only be passed if the buyer gave it. This goes far beyond the schema's descriptions.

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 explicitly states it finds products, verifies the seller, computes pricing/shipping, and returns ranked options awaiting approval — it does NOT pay yet. This specific verb+resource scope clearly distinguishes it from siblings like firestarter_approve and firestarter_shipping_estimate.

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?

It explicitly maps the full flow (firestarter_execute → review → firestarter_approve → firestarter_receipt/firestarter_track_order), names alternatives like firestarter_shipping_estimate for pre-purchase quotes, and provides when-to-use guidance for listing_id, location, delivery_address, auto_pay, and browse-only options. This is exemplary usage guidance.

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