Skip to main content
Glama

Checkout link for a list

checkout_list

Turn a quoted list into a payment link a person completes — the buyer gets the file within a minute of paying.

Creating the link costs nothing and charges nobody — payment only happens
if a human opens the returned `checkout_url` and completes it on Stripe's
hosted page. Hand the URL to your human; do not represent the purchase as
complete until they confirm payment. Nothing is charged until a person completes checkout; the file arrives about a minute after they pay; if we find a phone or email on the records after that, the updated file replaces it on the order's receipt page within a few hours and the receipt shows what was found and billed. A hard bounce, a disconnected phone or the wrong person is replaced within 30 days; what you buy is yours to re-download any time.

Pass a saved list (`list_id`, `#browse?list=<id>`) or the inline shape
`filters` + `states` (omit `states` for every live state:
CO, CT, FL, NY, TX, VA), a `lane` (`all` / `best` / `contact`) and an optional `cap`
(`{"type": "count|budget", "value"}` — records for count, cents for
budget). The list is quoted through the same summary path `quote_list`
uses, then checkout is opened against exactly that quote — if the price
rule or the count moved in between, the server answers 409 with the fresh
quote and nothing is minted. **Billing base is `sellable` (a matching
record whose filing names a person), never `matching`.** name and address $0.25 per record · plus one verified phone or email $0.50 · plus both $0.70 (price rule v1; live prices always come from the summary call's `prices` block). The
selected records are frozen when the link is minted, so what is billed is
what is delivered. After payment we go find a phone and email on every
record bought without one: the buyer authorizes a ceiling (`ceiling_cents` —
today's total plus the forecast upgrades), is charged `charged_now_cents` for
what exists now, and later only what we find, at that grade's price and
never above the ceiling. Every record ships the owner's name and mailing address plus the business facts — the business name, entity type and status, the state filing number and formation date, the industry with its NAICS, SIC and Google Business codes, the registered agent, the Lead Reference, and the Reachability, Contact Relevance and Contact Confidence scores; open the exact file before paying (ten made-up records, every column): https://app.goodleads.club/api/v1/commerce/sample-file?format=xlsx (or format=csv). A standing order on the same list (new matches on a
daily / weekly / monthly / quarterly cadence, billed monthly by the record
actually delivered, at the same graded rule) is set up from the paid
order's receipt — this tool sells the one-time purchase.

`delivery`: `file` (the customer workbook — CSV / Excel / JSON, yours to
re-download any time), `crm` (push into `crm_connection_id`), or
`connector` (the file ships today and `connector_crm_name` is recorded as
a request for that CRM).

`include_existing`: the order is Just started only — brand-new businesses —
unless you pass this (or name `filing_kind` / `business_origin` in
`filters`); then existing businesses with a new filing are in the file too,
labeled, and the file's Read Me says you asked for them.

`offer_code`: the offer code your human was given, if any — the same one
you quoted with. Every grade then bills at the lower of list and the
offer; a code bound to one buyer needs their `customer_email`; a code
that cannot cover the whole list answers with the cap to set.

Returns: `checkout_url`, `order_id`, `session_id`, `records`,
`total_cents`, `currency`, `lines` (one per grade), `lane`, `cap`,
`price_rule_version`, `quote_valid_until`, `computed_at`, `exact`,
`counts` (`matching`, `sellable`, `verified_one`, `verified_both`, `no_channel`, `unnamed`), `offer` (when a code priced it), `saved_list` (`id`, `url`, `name`, and the
one-time `claim_token` when this call saved an inline shape as a list),
`after_payment` and `guarantee` (the two sentences above, to relay), and —
when there are records to find on after payment — `ceiling_cents`,
`charged_now_cents` and `ceiling_note`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNo
laneNobest
statesNo
filtersNo
list_idNo
deliveryNofile
offer_codeNo
customer_emailNo
include_existingNo
crm_connection_idNo
connector_crm_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_existing
      Added value: +{
      +  "default": false,
      +  "title": "Include Existing",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / offer_code
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Offer Code"
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The description discloses that creating the link does not charge anyone, that payment only occurs when a human completes Stripe's hosted page, and that the file arrives about a minute after payment. It also explains post-payment enrichment, the ceiling charging model, replacement guarantees, and the traceability of records. These details go far beyond the sparse annotations (readOnlyHint=false, idempotent=false, destructive=false) and set accurate expectations for a state-changing commerce tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is over 800 words and repeats the same charging and delivery timing facts multiple times (e.g., 'Nothing is charged until a person completes checkout' appears in different wording throughout). It also includes a sample file URL and extensive pricing details that could be moved to linked documentation or the output schema. While front-loaded, many sentences do not earn their place, making it bloated rather than concise.

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 complex commerce tool with 11 parameters and no schema descriptions, this description covers every parameter, the full return field list, pricing rules, post-payment behavior, delivery options, and guarantees. It even provides a sample file URL and explains the difference from standing orders. No critical information is missing for an agent to call it correctly.

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?

With 0% schema description coverage, the description fully compensates by explaining every parameter: lane's allowed values, cap's object shape and unit semantics, delivery modes and their effects, include_existing's filter behavior, offer_code and customer_email requirements, the live states list, and crm/connector parameters. It gives exact formats and example values, which is far more than the bare schema titles provide.

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 first sentence clearly states the tool converts a quoted list into a payment link the buyer completes, with the file delivered within a minute. This is a specific verb and resource, and it distinguishes the tool from quote_list, which only produces a quote. The purpose is unmistakable even without reading the rest of the long description.

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?

The description gives concrete usage guidance: pass a saved list_id or inline filters/states, specifies acceptable lane values, and explains the one-time purchase nature while noting that standing orders are set up from the paid order's receipt. It also warns about 409 responses when the quote is stale. However, it never names an alternative tool like create_checkout, so an agent must infer when to prefer this over a sibling.

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