Skip to main content
Glama

GoodLeads

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).

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`), `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
customer_emailNo
crm_connection_idNo
connector_crm_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations are minimal (all false), so the description carries the full burden, and it does so richly. It discloses the critical behavior that no charge happens until a human completes checkout, that payment is via Stripe hosted page, that the file arrives about a minute after payment, and that after-payment enrichment may cause additional billing under a ceiling. It also explains the billing base ('sellable' not 'matching') and the 30-day replacement guarantee. This goes far beyond the annotation fields.

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

Conciseness3/5

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

The description is very long (over 800 words) and packs in a lot of detail. It is well-structured with clear paragraphs for pricing, delivery, and return fields, and it front-loads the primary purpose. However, its length may overwhelm an agent when parsing quickly, and some details (e.g., the exact sample-link URL) could be moved to an out-of-band reference. It is not concise, though it is efficient in that every sentence adds information.

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?

The description covers everything an agent needs to invoke the tool correctly: how to define the list, what parameters to use, what the return structure is, edge cases like 409 conflicts and 30-day guarantees, and even a sample file link for preview. The output schema exists and the description enumerates the fields returned. No important behavioral or operational context is missing.

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?

The description maps most parameters to their meaning: list_id, filters+states, lane, cap, delivery, crm_connection_id, connector_crm_name. It even explains the cap format and the pricing rule. However, it does not explicitly explain the customer_email parameter, which appears in the schema but is absent from the description. Given schema coverage is 0%, the description compensates well for the other eight parameters but leaves one gap.

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 and resource: 'Turn a quoted list into a payment link a person completes.' It clearly states the tool creates a one-time checkout link, and contrasts with a standing order on the same list. It also situates itself relative to quote_list by saying the list is quoted through the same summary path. This fully distinguishes it from siblings.

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?

Explicit when-to-use guidance is given: 'this tool sells the one-time purchase' and how to set up standing orders later via the receipt. It explains two ways to pass the list (list_id or inline filters+states), how to pick a lane, and what happens if the price changes (409 with fresh quote). It also tells the agent how to handle the URL: 'Hand the URL to your human; do not represent the purchase as complete until they confirm payment.' This is actionable and complete.

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