Skip to main content
Glama

GoodLeads

by club.goodleads
OverviewDiscussionsAdmin

Checkout link for a product or list

create_checkout

Mint a hosted Stripe Checkout link — for a shelf product, or for a list you shaped.

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, prefer the dedicated buying journey: `interpret_list` (the
buyer's words → a shape) → `quote_list` (graded counts + the price) →
`checkout_list` (this link, for a list). This tool remains for shelf
products (`product_id` from `list_products`, priced per list by the same
graded rule) and keeps accepting a list for compatibility — the list path
is the same code as `checkout_list`.

Two things you can buy:
  * a shelf product — `product_id` from `list_products`. `period`: `monthly` = a standing order billed each period; absent = a one-time purchase.
    The reply says which: `billing` (`monthly` | `one_time`), `price_cents`
    and a `note` that reads "This link starts a monthly standing order at
    $X per period" when the product carries a period; or
  * 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.

`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, for a list: `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). For a shelf
product: `checkout_url`, `order_id`, `session_id`, `billing`, `price_cents`,
`note`. 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
NameRequiredDescriptionDefault
capNo
laneNobest
statesNo
filtersNo
list_idNo
deliveryNofile
product_idNo
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.8/5.0
Behavior5/5

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

The annotations only say readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds substantial behavioral detail: creating the link charges nobody, payment happens only on human completion, stale quotes return 409, billing base is `sellable` not `matching`, selected records are frozen, delivery fires automatically on payment, and invalid contact data is replaced within 30 days. This goes far beyond the annotations and gives an agent trustworthy expectations.

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 core purpose and the critical no-charge caveat, then organized into clear sections for the two buyable paths, delivery, and return fields. It is verbose and repeats return-value details that the output schema likely already provides, but the structure keeps the extra length navigable. A tighter version could trim the return-field enumeration without loss.

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?

Given 10 optional parameters, no required fields, and sparse annotations, the description covers pricing rules, quote validity, 409 conflict behavior, delivery modes, billing basis, post-payment delivery timing, and replacement guarantees. The only notable gaps are customer_email and the `period` schema mismatch, but the overall context is sufficient for an agent to invoke the tool correctly and anticipate outcomes.

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 description coverage, the description carries the burden of explaining parameters, and it largely succeeds: it maps product_id to shelf products, list_id and inline filters/states to list purchases, lane and cap to quote shaping, and delivery/crm_connection_id/connector_crm_name to delivery behavior. However, it omits customer_email entirely and references a `period` option that does not appear in the input schema, which creates minor ambiguity. Despite that, it compensates impressively for the sparse schema.

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 names an exact operation and resource: "Mint a hosted Stripe Checkout link — for a shelf product, or for a list you shaped." It also differentiates from the sibling checkout_list by explaining that the list path uses the same code and remains for compatibility. The two purchase modes are explicitly laid out, so an agent knows exactly what the tool offers.

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 clearly says when to prefer the dedicated journey: "For new work, prefer the dedicated buying journey: interpret_list → quote_list → checkout_list." It then states when to use this tool instead: shelf products, or list compatibility. This is explicit routing guidance with named alternatives, not merely implied context.

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

All GoodLeads toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources