Payments Ops MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAYMENTS_OPS_DATA_DIR | No | The workspace directory for the server. Defaults to ~/.payments-ops-mcp if not set. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| reconcile_paymentsA | Three-way reconciliation of the order ledger, PSP captures and bank deposits. Fees are checked against the contract version in force on each transaction date. Payouts not yet due under the contract's payout delay show as in_transit, not missing. Args: date_from: First order date to include, YYYY-MM-DD (inclusive). Omit for all. date_to: Last order date to include, YYYY-MM-DD (inclusive). Omit for all. as_of: Date to judge payout lateness from, YYYY-MM-DD. Defaults to today. Returns a summary (match rate, value in breaks), warnings about missing data, per-payout settlement status, and every break with an id for explain_reconciliation_break. |
| explain_reconciliation_breakA | Explain one reconciliation break: what happened, likely causes, next steps and any related open disputes. Args: break_id: An id from reconcile_payments, e.g. BRK-duplicate_capture-ORD-1020. as_of: Same as_of used for reconcile_payments, if any. |
| list_open_disputesA | List chargebacks that need a response, most urgent first. Args: as_of: Date to count days left from, YYYY-MM-DD. Defaults to today. |
| triage_disputeB | Assess one chargeback: reason code, evidence on file, win likelihood and a fight/review/accept recommendation. Args: dispute_id: e.g. DSP-201. as_of: Date to count days left from, YYYY-MM-DD. Defaults to today. |
| draft_evidence_packA | Draft a plain-text evidence pack for a chargeback, for a person to review and submit. Args: dispute_id: e.g. DSP-201. as_of: Date to count days left from, YYYY-MM-DD. Defaults to today. |
| check_refund_policyA | Check whether a refund is allowed and who must approve it. Does NOT issue the refund. Args: order_id: e.g. ORD-1004. amount: Refund amount in major units, e.g. 24.99. reason: Why the customer wants a refund. as_of: Date to measure the refund window from, YYYY-MM-DD. Defaults to today. Returns decision = auto_approve | needs_human_review | reject, with reasons. |
| list_data_sourcesA | Show what data is loaded: sample or workspace mode, row counts, date ranges, contract versions, mapping profiles and which files are not imported yet. Call this first when setting up. |
| propose_contract_termsA | Validate contract terms extracted from a PSP contract or pricing schedule and stage them for confirmation. Nothing is saved yet. Call save_contract_terms after the person confirms. Args: psp_name: Payment provider name, e.g. "AcmePay". effective_from: Date the terms start, YYYY-MM-DD. card_fee_percent: Percentage fee as a percent, e.g. 2.9 for 2.9% (not 0.029). card_fee_fixed: Fixed fee per transaction in major units, e.g. 0.30. payout_delay_days: Days from capture to payout (e.g. 2 for T+2). currency: ISO currency code of the fees. international_surcharge_percent: Extra percent for international cards, if any. chargeback_fee: Fee per chargeback in major units, if any. reserve_percent: Rolling reserve percent, if any. sources: For each field above, the exact clause text it came from, copied verbatim. document_text: Full text of the contract, so each quote can be checked. Returns each term with a source check (verified / quote_not_found / number_not_in_quote / no_source), errors that block saving, warnings, changes versus the terms currently on file, and a proposal_id. |
| save_contract_termsA | Save proposed contract terms as a new version. Only call after the person has explicitly confirmed them. Args: proposal_id: The id returned by propose_contract_terms. confirmed: Must be true, meaning the person reviewed and approved the terms. |
| list_contract_versionsA | List the contract term versions on file with their effective dates. |
| preview_importA | Look at an export before importing it: detects CSV or CAMT.053, suggests a column mapping (or uses a matching saved profile), and shows normalised sample rows and errors. Args: target: One of orders, psp_transactions, bank_settlements, disputes. file_path: Path to the file on this computer. Use this or content. content: The file's text, if it was shared in the conversation instead. profile_name: A saved mapping profile to test against the file. |
| save_mapping_profileA | Save how a CSV layout maps to our fields, so the same export imports with no mapping step next time. Only call after the person agrees with the mapping shown by preview_import. Args: name: Profile name, e.g. "stripe-balance-report". target: One of orders, psp_transactions, bank_settlements, disputes. columns: Our field -> their column header, e.g. {"psp_ref": "balance_transaction_id"}. amount_unit: "major" if amounts look like 24.99, "minor" if they look like 2499. defaults: Values for fields the file lacks, e.g. {"currency": "USD"}. value_maps: Value translations per field, e.g. {"type": {"charge": "capture"}}. date_format: strptime format if dates are not ISO, e.g. "%d/%m/%Y". batch_ref_pattern: Regex to find the payout id in bank references, e.g. "PO-[0-9]+". |
| import_transactionsA | Import an export into the workspace. CSV needs a saved mapping profile; CAMT.053 bank statements need none. Rows already imported (same id) are skipped, so re-importing a file is safe. Args: target: One of orders, psp_transactions, bank_settlements, disputes. profile_name: Saved mapping profile (CSV only). file_path: Path to the file on this computer. Use this or content. content: The file's text, if it was shared in the conversation instead. mode: "append" (default) adds new rows; "replace" swaps out everything for this target. batch_ref_pattern: For CAMT.053, regex to find the payout id in references. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| daily_payments_ops_review | Morning review: reconciliation breaks, urgent disputes and what to do first. |
| onboard_my_payments_data | Guided setup: contract terms from your PSP contract, then your exports. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| reason_codes | Simplified chargeback reason codes, categories and the evidence each needs. |
TDQS
Scored across 13 tools
Each tool targets a distinct resource and action: refund policy, reconciliation, break explanation, disputes, contracts, and import each have clearly separate tools with no functional overlap. Even the potentially confusable pairs (propose_contract_terms vs save_contract_terms, preview_import vs import_transactions) are explicitly staged with descriptions clarifying sequencing. Descriptions proactively prevent misselection (e.g. check_refund_policy 'Does NOT issue the refund').
Every tool follows a consistent verb_noun snake_case pattern: check_refund_policy, list_contract_versions, explain_reconciliation_break, draft_evidence_pack, save_mapping_profile, import_transactions. There are no camelCase or other convention deviations, and verbs are used consistently for the same class of action (list_*, save_*, propose_*).
13 tools fall squarely in the well-scoped range, and each maps to a real operational step (setup, ingest, reconcile, explain, dispute, contract). No redundant or filler tools are present; each earns its place in the payments-ops workflow.
Coverage is strong across ingestion (preview/save_mapping/import), reconciliation (reconcile + explain), disputes (list/triage/draft), and contract lifecycle (list/propose/save). Minor gaps: there is no refund issuance tool (check_refund_policy explicitly stops short), no dispute submission, and no contract update/delete, but these appear to be intentional human-in-the-loop handoffs that agents can route around.