Skip to main content
Glama

list_subscription_payments

Read-only

Retrieve a paginated list of subscription payment records for your Checkout Page account. Each record represents one per-Stripe-invoice charge against a subscription — a billing cycle payment, renewal, or failed attempt. Subscriptions rarely accumulate more than 24–36 payment records (2–3 years of monthly billing), so limit: 100 typically retrieves the full history for a single subscription in one call.

Pass livemode: false to read test-mode records.

Cross-tool routing:

  • Per-payment subscription history → this tool (list_subscription_payments)

  • Parent subscription record (status, plan, trial, coupon) → list_subscriptions

  • One-time payment charges → list_payments

  • Event/booking charges → list_bookings

Records do NOT overlap between tools — a transaction only appears in one tool. No risk of double-counting when combining results.

This tool is read-only. You cannot process refunds, cancel subscriptions, update payment methods, or retry failed payments. For these actions, explain what is currently on file. The merchant can manage subscription payments in the Checkout Page dashboard. The customer can update their payment method through the customer portal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paidNoFilter by whether the invoice was fully collected. `true` = invoice paid in full, `false` = unpaid (use for "show me unpaid invoices"). Convenience field — an invoice can be `paid: true` even after a failed attempt followed by a successful retry.
limitNoNumber of records per page (integer, max 100, default 10).
pageIdNoFilter subscription payments by page ID.
livemodeNoSet to false to read test-mode records (created while a page was in test mode). Defaults to live records.
refundedNoFilter by whether the payment was refunded. Combine with `createdAfter` to scope to a time window (e.g. "show me refunded subscription payments this month").
customerIdNoFilter subscription payments by customer ID.
createdAfterNoFilter by lower bound of `createdAt`. Use a UTC ISO 8601 timestamp with the `Z` suffix (e.g. `2026-03-01T00:00:00Z`). Never use local timezone offsets — dates are stored and compared in UTC.
billingReasonNoFilter by reason the invoice was generated. Valid values: manual, subscription_create, subscription_cycle, subscription_threshold, subscription_update, upcoming. `subscription_create`: first payment when the subscription is created and activated; the customer's initial charge. `subscription_cycle`: standard renewal at the end of a billing period. `subscription_update`: charge from a plan change or proration; can explain an unexpected charge after switching plans. `subscription_threshold`: metered billing usage threshold trigger. `manual`: manually triggered by the merchant. `upcoming`: preview of an upcoming invoice; not yet charged.
createdBeforeNoFilter by upper bound of `createdAt`. Use a UTC ISO 8601 timestamp with the `Z` suffix (e.g. `2026-03-31T23:59:59Z`). Never use local timezone offsets — dates 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`.
paymentStatusNoFilter by status of the underlying Stripe charge or payment intent. Valid values: succeeded, pending, failed, incomplete. Use `failed` to find failed attempts (e.g. "show me failed subscription payments"). Note: a record can have `paymentStatus: 'failed'` while the invoice is still `open` — if a later retry succeeded, both `paymentStatus` and `paid` reflect success. For overall invoice lifecycle use the `invoiceStatus` field on the response; for a simple "was this paid?" check use `paid`.
starting_afterNoCursor-based pagination. Pass a record `id` to return results after it. Cannot be used with `ending_before`.
subscriptionIdNoFilter by parent subscription ID. Use to retrieve the full per-cycle payment history for one subscription (e.g. "show me payments for subscription X" or "when was subscription X last charged?"). Results are newest-first by default, so the first record is the most recent payment.

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.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is pre-covered and the restated 'read-only' line is partly redundant. The description does add genuine context beyond annotations: the non-overlap guarantee that prevents double-counting, the scale heuristic (24-36 records, so limit 100 usually gets full history), and the test-mode livemode:false behavior.

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?

Front-loads purpose, then routing, then constraints, with bullets doing real work. It is on the longer side and the closing read-only paragraph restates annotation-provided facts, but no sentence is filler and the routing table is dense with useful routing 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?

With an output schema present, the description need not explain return values. Between the record definition, routing, scale expectations, test-mode note, and read-only scope, an agent has everything needed to call this 13-parameter tool correctly without consulting other tools.

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?

Schema description coverage is 100%, so the baseline is 3 regardless. The description goes slightly beyond by giving the practical heuristic that limit: 100 retrieves the full per-subscription history and by calling out livemode: false for test mode, which helps an agent pick parameter values rather than just read their types.

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?

States a specific verb and resource ('Retrieve a paginated list of subscription payment records') and immediately defines what a record represents (one per-Stripe-invoice charge against a subscription). It explicitly differentiates from siblings by naming list_subscriptions, list_payments, and list_bookings and asserting the result sets do not overlap.

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?

Contains an explicit cross-tool routing block mapping four distinct intents to four tools, plus a when-not-to-use clause: it cannot refund, cancel, update payment methods, or retry payments, and it names the fallback (explain what is on file, dashboard, customer portal). Alternatives and exclusions are both given.

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