Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PAYMENTS_MODENoRuntime mode: mock, sandbox (default), or live. Mock needs no credentials; sandbox/live require the relevant gateway credentials via environment variables.sandbox
MCP_HTTP_TOKENNoBearer token (24+ characters) required when running the HTTP transport. Not required for the default stdio transport.
PAYMENTS_AUDIT_LOGNoPath to append audit log entries as JSON Lines for create, refund and subscription actions.
PAYMENTS_ALLOW_LIVE_MUTATIONSNoSet to true to allow live-mode refunds and subscription cancellations. Live mutations also require confirm: true on the call.

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
payments_list_providersA

List every supported gateway with a one-line summary, whether credentials are configured, and the feature support matrix.

payments_get_capabilitiesA

Full capability map for one gateway: features (supported / partial / not_implemented / unsupported), payment methods, required env vars, hard constraints, official SDKs and platform plugins (Shopify, WooCommerce).

payments_check_configA

Doctor: shows the mode and which environment variables are present or missing per gateway. Never returns secret values.

payments_recommend_gatewayB

Rank gateways for a use case using the capability map (e.g. subscriptions, international payments, Shopify, lowest integration effort).

payments_create_paymentA

Create an order / payment session. Returns checkout, which tells the frontend what to do: js_sdk (load script + options), redirect (send the browser to url), form_post (auto-submit a form with fields), or manual. Persist orderRef + providerOrderId.

payments_verify_paymentA

Verify the payload the browser/app received after checkout (Razorpay handler response, PayU/CCAvenue/Paytm POST-back, etc.). Fulfil ONLY when paid=true. valid=true just means the callback is genuine; a genuine failure is still valid. For gateways that do not sign callbacks it confirms through the status API.

payments_get_statusA

Fetch the authoritative payment status from the gateway (source of truth for reconciliation).

payments_refundA

Refund all or part of a captured payment. refund_ref is the idempotency key: re-sending it after a success returns the same refund. If a call fails with OUTCOME_UNKNOWN, check payments_get_refund_status / payments_get_status BEFORE retrying. In live mode this moves real money: ask the human first, then pass confirm=true.

payments_get_refund_statusC

Fetch refund status from the gateway.

payments_verify_webhookA

Verify a webhook signature and normalise it into a common event (payment.succeeded, refund.processed, ...). Pass the RAW body string exactly as received.

payments_simulate_webhookA

Produce a correctly signed webhook (headers + raw body) for local testing. In sandbox mode it uses the provider's real signing scheme and your webhook secret; replay it with curl against your LOCAL endpoint. Disabled in live mode. Never reuse sandbox webhook secrets in production.

payments_create_customerC

Create a customer record on gateways that have one (Razorpay, Stripe).

payments_create_subscriptionB

Create a recurring subscription (UPI Autopay / card e-mandate). Returns a checkout action the customer must complete to authorise the mandate.

payments_cancel_subscriptionA

Cancel a subscription now or at cycle end. Live mode requires confirm=true after human approval.

payments_list_settlementsA

List settlements (payouts from the gateway to your bank) for reconciliation.

payments_generate_integrationA

Generate a working, production-shaped integration for a project: server routes (create order, verify callback, webhook), client checkout code, env template and a test checklist. Returns files with paths and contents for the agent to write.

payments_mock_complete_paymentA

MOCK MODE ONLY. Simulate the customer finishing checkout. Returns a signed callback payload (feed it to payments_verify_payment) and the updated payment.

Prompts

Interactive templates invoked by user choice

NameDescription
integrate_paymentsStep-by-step plan for adding a gateway to the current project.

Resources

Contextual data attached and managed by the client

NameDescription
support-matrixFeature support across all gateways (Markdown)
razorpay capabilitiesCapability map for one gateway (JSON)
payu capabilitiesCapability map for one gateway (JSON)
cashfree capabilitiesCapability map for one gateway (JSON)
ccavenue capabilitiesCapability map for one gateway (JSON)
paytm capabilitiesCapability map for one gateway (JSON)
phonepe capabilitiesCapability map for one gateway (JSON)
stripe capabilitiesCapability map for one gateway (JSON)
skydo capabilitiesCapability map for one gateway (JSON)

TDQS

A3.6/5.0

Scored across 17 tools

Disambiguation4/5

Most tools target a distinct resource+action (create_payment, refund, verify_webhook, simulate_webhook, mock_complete_payment are clearly separated by mode/purpose). There is mild overlap among the four introspective tools — list_providers vs get_capabilities vs check_config vs recommend_gateway all describe gateway metadata/env vars, and get_status vs verify_payment require reading the descriptions carefully to distinguish authoritative fetch from callback validation.

Naming Consistency5/5

Every tool uses the same payments_ prefix followed by a consistent snake_case verb_noun pattern (payments_get_status, payments_create_subscription). No mixing of conventions or vague one-word verbs.

Tool Count4/5

17 tools is slightly above the ideal 3-15 band but justifiable given multi-gateway support plus subscription, webhook, settlement and scaffolding flows. Each tool maps to a real integration step rather than padding.

Completeness4/5

Core lifecycle is well covered: create/verify/status, refund + refund status, webhooks (verify/simulate), subscriptions create/cancel, customers, settlements and integration generation. Gaps remain for read/list operations — no list_payments/orders, get_subscription, list_subscriptions, or capture of authorised payments — which would be needed for full reconciliation and subscription management.

Maintenance

ActivityMaintained
ResponsivenessNo issues