Feature Request: Add subscription_schedules and charges support to the Stripe MCP connector

[freek-aizy]

Is your feature request related to a problem? Please describe.

Feature Request: Add subscription_schedules and charges support to the Stripe MCP connector

Summary

The current Stripe MCP connector is missing two commonly needed Stripe API resources:

1. /v1/subscription_schedules — for fetching planned/future subscriptions
2. /v1/charges — for fetching payment attempts including failed and Radar-blocked payments

Without these, AI assistants using the MCP connector have a significant blind spot in subscription billing and cash flow reporting workflows.

---

Problem

Subscription Schedules:

The current fetch_stripe_resources tool only supports the following prefixes: pi_, ch_, in_, price_, prod_, sub_, cus_. The prefix sub_sched_ is explicitly unsupported, returning No such subscription: 'sub_sched_...'.

This means any subscription created as a schedule (i.e. with a future start date via the Stripe Dashboard or API) is completely invisible to the MCP connector. In our case, this hides 15 planned subscriptions representing €38,250 in expected April billing — a meaningful gap for any revenue forecasting workflow.

Charges:

The search_stripe_resources tool lists charges as a supported resource type, but the underlying MCP API key does not have charges:read permissions by default, resulting in:

Permission error: The provided key 'ek_live_...' does not have the required
permissions for this endpoint.

Failed and Radar-blocked charges are critical for cash flow monitoring. Without this, teams cannot ask their AI assistant about payment failures, chargeback risks, or Radar rule outcomes.

---

Requested Changes

1. New tool: list_subscription_schedules

list_subscription_schedules(
  status: "not_started" | "active" | "completed" | "released" | "canceled",
  limit: int,              # 1–100
  starting_after: str      # cursor-based pagination
)

Maps to: GET /v1/subscription_schedules

Should return: schedule ID, status, customer, start date, phases (price, quantity, interval), and optionally enriched with product name.

2. Extend fetch_stripe_resources to support sub_sched_ prefix

Maps to: GET /v1/subscription_schedules/{id}

Allows fetching a single schedule by its ID — consistent with how sub_ IDs are handled today.

3. New tool: list_charges

list_charges(
  limit: int,              # 1–100
  created_gte: int,        # Unix timestamp
  created_lte: int,        # Unix timestamp  
  customer: str,           # optional filter
  starting_after: str      # cursor-based pagination
)

Maps to: GET /v1/charges

Should return: charge ID, status, amount, currency, customer, failure_message, outcome (type, reason, Radar rule), created timestamp.

4. Add starting_after pagination to all existing list_* tools

Currently all list tools have a hard cap of 100 records with no way to paginate. The Stripe API supports cursor-based pagination via starting_after. Without this, accounts with more than 100 subscriptions will silently miss records.

---

Impact

Gap	Business impact
No subscription_schedules	Future revenue is invisible — new customers with a scheduled start date don't appear in any MCP-based forecast
No charges access	Failed payments and Radar blocks can't be queried — cash flow reporting is incomplete
No pagination	Any account with 100+ subscriptions gets silently truncated data

---

Workaround We're Currently Using

As a temporary bridge, we built a standalone HTML artifact that calls /v1/subscription_schedules and /v1/charges directly from the browser using a Stripe Restricted Key (read-only). This works but requires a separate key and manual steps — it is not a sustainable solution.

---

Stripe API Reference

• https://docs.stripe.com/api/subscription_schedules/list
• https://docs.stripe.com/api/subscription_schedules/retrieve
• https://docs.stripe.com/api/charges/list
• https://docs.stripe.com/api/pagination

---

Environment

• MCP connector: https://mcp.stripe.com/sse
• Claude.ai (Anthropic) with Stripe MCP connector enabled
• Live mode, EUR currency, Netherlands

---

Happy to test any implementation. Thanks for maintaining this connector , it's already very useful for the endpoints it does support.

[freek-aizy]

any updates about this topic?