Skip to main content
Glama

list_invoices

Read-only

List invoices generated from payments (Charges) on the Checkout Page account. Pass livemode: false to read test-mode records. Each invoice's invoiceUrl links to its hosted PDF, the document customers usually ask for. The link is signed, safe to share with the buyer, and expires 1 hour after the response. Read-only; for full purchase history also query list_payments, list_subscriptions, list_subscription_payments and list_bookings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of records per page (integer, max 100, default 10).
searchNoCase-insensitive search matched against `customerEmail`, `customerName`, `productTitle` and `invoiceNumber`. The query is routed based on input shape: email-like inputs (`jane@example.com`) match `customerEmail` only; identifier-like inputs containing a digit/underscore/hyphen (`2026-000010`) match `invoiceNumber`; multi-word inputs match `customerName` and `productTitle`; any other single bare word falls back to a broad case-insensitive substring match across `customerName`, `customerEmail` and `productTitle`. Best default when the user gives an ambiguous query. A customer may have multiple invoice records — always review all matches, not just the first.
statusNoFilter by invoice status. Only one status per call. Valid values: draft, open, paid, uncollectible, refunded, partially_refunded, void. Use "paid" for completed invoices, "open" for outstanding, "refunded" or "partially_refunded" for refund history, "void" for cancelled. Filter by status when counting a category — an unfiltered total includes drafts and voids.
chargeIdNoReturn invoices for a specific payment (Charge). Use when a customer asks for a copy of their invoice and you already have the originating payment ID. Most charges have one invoice.
livemodeNoSet to false to read test-mode records (created while a page was in test mode). Defaults to live records.
poNumberNoExact match on the invoice PO number. Use for "find the invoice for PO-5678".
customerIdNoReturn all invoices for a specific customer. Useful when you already have the customer record (e.g. from get_customer or list_customers).
createdAfterNoInclusive lower bound on invoice createdAt. ISO-8601 UTC datetime with the `Z` suffix (e.g. `2026-01-01T00:00:00Z`). Never use a local timezone offset — invoices are stored and compared in UTC.
createdBeforeNoInclusive upper bound on invoice createdAt. ISO-8601 UTC datetime with the `Z` suffix (e.g. `2026-12-31T23:59:59Z`). Never use a local timezone offset — invoices are stored and compared in UTC.
ending_beforeNoCursor-based pagination. Pass a record `id` to return results before it. Cannot be used with `starting_after`.
starting_afterNoCursor-based pagination. Pass a record `id` to return results after it. Cannot be used with `ending_before`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
totalYesTotal number of records matching the query across all pages.
has_moreYesWhether more records exist beyond the current page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), but the description adds genuinely new behavior: the invoiceUrl is a signed, shareable link that expires 1 hour after the response, and it reiterates the read-only nature. That expiry/shareability detail is not derivable from annotations or schema.

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?

Four sentences, front-loaded with purpose and scope, followed by the livemode hint, the invoiceUrl caveat, and sibling routing. Every sentence carries information, though it is slightly denser than strictly necessary.

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 11 optional parameters fully documented in the schema, an output schema present, and annotations covering safety, the description supplies the remaining operational context an agent needs: test-mode switching, link expiry, and where to look for broader purchase history. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema, including the search routing rules and UTC date-time constraints. The description only restates the livemode usage hint and references invoiceUrl (a response field, not a parameter), adding little beyond the structured data. Baseline 3 applies.

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 states a precise verb and resource with scope: invoices generated from payments (Charges) on the Checkout Page account. It also names the sibling list tools that cover adjacent purchase-history data, so an agent can distinguish it without opening a schema.

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?

It gives concrete routing guidance: use livemode:false for test-mode records, and query list_payments/list_subscriptions/list_subscription_payments/list_bookings for full purchase history. It stops short of an explicit 'when not to use this' (e.g., use get_invoice for a single known invoice), so it falls just short of a 5.

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