mcp-ops
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENTRY_ORG | No | Sentry organization slug. Required if using Sentry service. | |
| SENTRY_URL | No | Optional Sentry URL (for self-hosted instances). | |
| GITHUB_REPO | No | GitHub repository in owner/name format. Required if using GitHub service. | |
| DATABASE_URL | No | Postgres connection string (read-only role or replica). Required if using Postgres service. | |
| GITHUB_TOKEN | No | GitHub token with read access to Contents, Actions, and PRs. Required if using GitHub service. | |
| NEON_API_KEY | No | Neon API key. Required if using Neon service. | |
| NETLIFY_SITE | No | Optional Netlify site name. | |
| SENTRY_TOKEN | No | Sentry API token with project:read and event:read permissions. Required if using Sentry service. | |
| SHOPIFY_SHOP | No | Shopify shop domain (e.g., your-store.myshopify.com). Required if using Shopify service. | |
| VERCEL_TOKEN | No | Vercel API token (team-scoped). Required if using Vercel service. | |
| NETLIFY_TOKEN | No | Netlify personal token. Required if using Netlify service. | |
| RENDER_API_KEY | No | Render API key. Required if using Render service. | |
| RESEND_API_KEY | No | Resend read key. Required if using Resend service. | |
| SENTRY_PROJECT | No | Sentry project slug. Required if using Sentry service. | |
| VERCEL_PROJECT | No | Optional Vercel project name. | |
| VERCEL_TEAM_ID | No | Optional Vercel team ID. | |
| CLOUDFLARE_ZONE | No | Optional Cloudflare zone identifier. | |
| NEON_PROJECT_ID | No | Optional Neon project ID. | |
| BETTERSTACK_TOKEN | No | Better Stack team token. Required if using Better Stack service. | |
| STRIPE_SECRET_KEY | No | Stripe API key (restricted, read scopes). Required if using Stripe Connect. | |
| TWILIO_AUTH_TOKEN | No | Twilio auth token. Required if using Twilio service (along with TWILIO_ACCOUNT_SID). | |
| TWILIO_ACCOUNT_SID | No | Twilio account SID. Required if using Twilio service (along with TWILIO_AUTH_TOKEN). | |
| CLOUDFLARE_API_TOKEN | No | Cloudflare API token with Zone:Read and DNS:Read permissions. Required if using Cloudflare service. | |
| SHOPIFY_ACCESS_TOKEN | No | Shopify access token with read_orders scope. Required if using Shopify service. | |
| POSTMARK_SERVER_TOKEN | No | Postmark server token. Required if using Postmark service. | |
| STRIPE_MCP_ALLOW_LIVE | No | Set to '1' to allow live Stripe keys. Defaults to false. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| stripe_list_accountsB | List the connected accounts of this Stripe Connect platform with their status (charges, payouts, requirements due). |
| stripe_get_accountA | Full status of one connected account: capabilities, requirements, external accounts (last4 only), dashboard type. |
| stripe_diagnose_accountA | Explain why a connected account cannot charge or get paid out: disabled reasons, past-due requirements, capabilities, missing bank account, TOS. |
| stripe_balanceA | Available and pending balance per currency, for the platform (no account_id) or for one connected account. |
| stripe_list_transfersC | Transfers from the platform to connected accounts: amount, currency, destination, funding charge, reversals. |
| stripe_diagnose_transferA | Given a transfer id (tr_...) or a charge id (ch_...), check what makes Connect transfers fail: settlement currency of the source charge vs the transfer currency, amount above the charge net, platform balance too low, destination with payouts disabled, refunds and disputes. |
| stripe_list_chargesB | Recent charges on the platform, or on one connected account (direct charges) when account_id is given. Shows destination, application fee and attached transfer. |
| stripe_list_payoutsB | Payouts from a connected account to its bank, with status, arrival date and failure reason. |
| stripe_list_webhook_endpointsC | Webhook endpoints of the platform with their status, API version and enabled events. |
| stripe_list_eventsA | Recent Stripe events. Filter by type ("payment_intent.succeeded") or by prefix ("payment_intent."). only_undelivered=true lists events whose webhook delivery is still failing. |
| stripe_get_eventA | One event with its payload (clipped), pending webhook count and the request that caused it. |
| ops_statusA | One line per connected service (stripe): balances, blocked accounts, failing webhooks, last deploy, open errors, bounced emails, database size and connections. Start here. |
| ops_timelineA | One chronological list mixing deploys, commits, CI runs, payments, errors, emails, SMS, incidents and database operations from every connected service, for the last N minutes. The fastest way to answer "what changed before things broke". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct resource or action: list/get/diagnose split account lookup from troubleshooting, and transfer diagnostics are clearly separated from transfer listing. Even the two ops-level tools differ in purpose: status is a snapshot summary while timeline is a chronological event view.
The stripe_ prefix with list_/get_/diagnose_ verbs is highly consistent, and ops_ follows the same resource_scope pattern. Minor deviations are stripe_balance (a noun instead of get_balance) and ops_status/ops_timeline being noun-only, but the pattern remains predictable.
Thirteen tools cover the Stripe Connect operational surface at a reasonable granularity without redundancy. The count sits comfortably below the heavy threshold and each tool has a clear role, from account diagnostics to event inspection and cross-service status/timeline.
The surface covers the core read/diagnose workflows: accounts, balances, charges, transfers, payouts, events, webhooks, and aggregate ops views. Minor gaps remain, such as no dedicated refund/dispute list or single-transfer getter, but most can be worked around via events and diagnostic tools.