stripe

This OAuth session may expose both live and sandbox Stripe accounts. Discover the live account-selection tools, select the intended account and mode, then carry exact context fields such as stripe_context and livemode wherever the schema requires them. A live-mode write moves real money; a sandbox write changes test data. Never infer the account or mode from connector metadata.

• Discover account and mode with the live account-selection tools before every account-scoped read or write. The published inventory has changed account-tool names; do not assume list_available_accounts_or_orgs is available. Select the intended result and carry the exact context fields required by the live schema unchanged. If the account, mode, or supported selector is ambiguous, stop and ask; never guess.
• Organization accounts are not Stripe Connect connected accounts. A Connect call requires a separate API-key connector whose connectedAccount sends Stripe's documented Stripe-Account header; OAuth does not support that path.
• Four generic tools reach any Stripe API method. Find the method with stripe_api_search, read its parameters with stripe_api_details, then call stripe_api_read (GET) or stripe_api_write (POST/PATCH/PUT/DELETE). Never guess a path or a parameter name — stripe_api_details is cheaper than a rejected write.
• Prefer a dedicated tool when one covers the task: get_balance_summary for balances and stripe_analytics for Sigma or Metrics reporting. Use stripe_api_search for everything else instead of assuming a retired dedicated tool still exists.
• stripe_implementation_planner and the query-execution intents of stripe_analytics create provider-side planning or query-run state. Connecta therefore classifies both as writes, which a read-only endpoint refuses; their retrieval paths stay behind the same tool boundary.
• stripe_api_write carries the blast radius of the entire write API — every POST, PATCH, PUT, and DELETE, from a customer edit to a subscription cancellation. State the method and path explicitly; a read-only endpoint refuses it.
• Any stripe_api_read list or stripe_api_search that returns full objects belongs inside execute_code, projected to the fields the question needs before return. Neither limit nor expand substitutes for that: an unprojected list of customers or invoices truncates long before it answers, and a projected one keeps the customer's name, email, and address out of the transcript.
• Find an object with stripe_api_search (or a list endpoint through stripe_api_read) and carry the id it returned into the write.
• This connection's tool list is not a fixed set. Stripe gates parts of its MCP catalog by account, integration, and beta enrollment, so search this connector for what it actually exposes rather than assuming a documented tool is here.
• Send an Idempotency-Key on every write you might retry, if the tool accepts it, and reuse the same key for the retry. A retry with a fresh key is a second charge, not a second attempt.

• This is Connecta's REST connector to api.stripe.com, holding one operator-managed key. It reaches exactly one account in one mode, so there is no account selection and no stripe_context or livemode argument.
• stripe_api_search finds API operations, not records: it searches the pinned API index and names the tool that calls each operation. stripe_api_details returns one operation's parameters with types, enums, and required names. Neither sends a request.
• stripe_api_read calls GET operations, plus POST /v1/invoices/create_preview, which only previews. stripe_api_write calls every other POST and every DELETE, from a customer edit to a subscription cancellation, with method and path stated; a read-only endpoint refuses it.
• Paths are concrete: substitute ids into the template search returned (/v1/payment_intents/pi_123). Pass query and body as JSON objects named as stripe_api_details lists them. Connecta form-encodes v1 bodies and query lists (expand: ["latest_charge"]), sends v2 bodies as JSON, and pins Stripe-Version to the index's API version. Send null or "" to unset a field.
• Every call is checked against the pinned index before it is sent. An unknown path returns the nearest operations; an unknown or missing parameter returns validation.issues with the accepted names. Nothing reached Stripe, so fix the call from that answer.
• Results arrive as { status, data, page? }. On a list, page.next is the cursor and page.param the query parameter to pass it as: starting_after, or page for search and v2 lists. Lists belong inside execute_code; pass select (dot paths such as data.id and data.status) to keep only the fields the question needs, which also keeps customer names, emails, and addresses out of the transcript.
• get_stripe_account_info confirms the account, mode, and connected account; get_balance_summary returns available and pending balances. Use them when they answer the question.
• Find records with list and search operations through stripe_api_read (GET /v1/customers/search, GET /v1/charges with customer) and carry the returned id into the write.
• stripe_api_write sends an Idempotency-Key on every POST. Pass idempotencyKey for anything you might retry, or reuse the generated one the result returns. An ambiguous failure carries it in its message or as uncertainCall.recovery.idempotencyKey. Reuse it only with the exact original arguments and within Stripe's retention (v1 keys may be pruned after 24 hours); after that, look the object up before retrying. A retry with a fresh key is a second charge, not a second attempt.
• Refused by design: operations that hand out a credential (ephemeral keys, Terminal connection tokens, account links (v1 and v2), Terminal onboarding links, Express login links, account sessions, customer sessions, billing portal sessions, file link creation, Financial Connections session creation, and the meter event session), Stripe Apps secret payloads (expand of payload), Issuing card number and cvc expansion on any Issuing path, multipart uploads such as POST /v1/files (use the Dashboard), and the meter event stream (send single events with POST /v2/billing/meter_events). Each refusal names its reason. Quote PDFs arrive from files.stripe.com as base64.
• Secrets read as "[redacted]" in every result, expansions included: client secrets (PaymentIntents, SetupIntents, Checkout and Identity sessions, Sources, Financial Connections, invoice confirmation secrets), webhook and event destination signing secrets, Apps secret payloads, app-install authorization codes, Terminal Wi-Fi passwords, forwarded request header values, and Issuing card numbers and CVCs. Webhook and event destination URLs, file link URLs (in an expanded File, a list, or an event too), and pre-signed import URLs keep only their scheme and host. Identity verification urls come back whole. A Checkout Session's url comes back whole only for a guest payment session (mode: "payment", no customer or customer_account, no customer creation, no saved payment method options); any other session returns only its scheme and host, because its page can show, reuse, or remove a customer's saved payment methods. Create those from your own server code, or send a payment link or the invoice's hosted page instead. These rules follow each object wherever it appears, expansions and events included. A [redacted] field is never the real value; do not send it back.
• Failures of credential-bearing operations (webhook endpoints, Apps secrets, Terminal configurations, forwarding) carry Stripe's type, code, decline code, and param, not its message. Payment, billing, and account failures keep Stripe's message.
• The hosted OAuth connection's natural-language Sigma, metrics, documentation search, implementation planner, and feedback tools do not exist with a key.