GoodLeads

Checkout link for a list (older name)

create_checkout

Mint a hosted Stripe Checkout link for a list you shaped — the same code as checkout_list.

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.

For new work, use the dedicated buying journey: `interpret_list` (the
buyer's words → a shape) or `list_starters` (ready-made lists with live
counts) → `quote_list` (graded counts + the price) → `checkout_list`
(this link). This tool keeps accepting a list for compatibility — the
list path is the same code as `checkout_list`.

What you can buy: a list — `list_id` (a saved list, `#browse?list=<id>`) or the
inline shape `filters` + `states` (omit `states` for every live state:
CO, CT, FL, NY, TX, VA), with 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 code path `browse_leads(summary=True)`
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.

`product_id` buys nothing: fixed-price shelf products were replaced by
starter lists with live counts. Passing one returns an error that names
the next calls — `list_starters` (or `interpret_list`), `quote_list`,
`checkout_list`. Every purchase is one-time; a standing order is set up
from a paid order's receipt, billed monthly for the records actually
delivered.

`delivery`: `file` (the customer workbook — CSV / Excel / JSON, durable
re-download), `crm` (push into `crm_connection_id`), or `connector`
(the file ships today and `connector_crm_name` is recorded as a request
for that CRM). Delivery fires automatically on payment, typically within
a minute.

Returns: `checkout_url`, `order_id`, `session_id`, `records`,
`total_cents`, `currency`, `lines` (one per grade), `lane`, `cap`,
`price_rule_version`, `quote_valid_until` (counts refresh tomorrow
morning; the quote holds until then — and the frozen selection holds for
the life of the checkout session), `computed_at`, `exact`, `counts`
(`matching`, `sellable`, `verified_one`, `verified_both`, `no_channel`, `unnamed`), and `saved_list` (`id`, `url`, `name`, and the one-time
`claim_token` when this call saved an inline shape as a list).
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.

Input Schema

TableJSON Schema

Name	Required	Default
`cap`	No
`lane`	No	best
`states`	No
`filters`	No
`list_id`	No
`delivery`	No	file
`offer_code`	No
`product_id`	No
`customer_email`	No
`crm_connection_id`	No
`connector_crm_name`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

addedInput schema / properties / offer_code

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Offer Code"
+}

First observedSep 10, 2026

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 hints), so the description carries the full burden and exceeds it. It discloses that payment only happens on Stripe's hosted page, that billing base is `sellable` not `matching`, that a 409 is returned if the quote changed, that records are frozen at mint time, that delivery fires automatically, and even covers replacement/bounce policy. 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.

Conciseness3/5

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

The description is dense and informative but noticeably long and somewhat repetitive: 'the same code as `checkout_list`' appears twice, and the return-field enumeration overlaps with the provided output schema. It is well-paragraphed and front-loaded, but it could be tightened without losing value.

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 an 11-parameter tool with no schema description coverage, the description is remarkably complete. It covers pricing, quote validity, delivery timing, error behavior, standing orders, and edge cases like state omission. The output schema already exists, so the detailed return list is bonus context rather than a required gap.

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?

With 0% schema coverage, the description must compensate and mostly does: it explains `list_id` vs inline `filters` + `states`, `lane` values, `cap` shapes, `delivery` modes, `product_id` deprecation, and CRM-related parameters. It leaves `offer_code` and `customer_email` undocumented, which is a small gap in an otherwise thorough parameter treatment.

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: 'Mint a hosted Stripe Checkout link for a list.' It immediately distinguishes itself by stating it is the 'older name' and 'the same code as `checkout_list`,' so an agent can clearly tell this tool apart from its sibling despite overlapping functionality.

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 explicitly lays out the recommended buying journey (`interpret_list` or `list_starters` → `quote_list` → `checkout_list`) and says this tool remains for compatibility. It also warns that `product_id` should not be used and names the alternative calls in the error path, giving clear when-to-use and when-not-to-use guidance.

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

All GoodLeads tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?