Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BLINDPAY_API_KEYYesYour BlindPay API key. Create an account on BlindPay, create a development instance, go to the BlindPay Dashboard, select your instance and click on the API Keys tab, then create a new API key.

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
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
GetV1InstancesOnboardingBusinessDetailsC

Retrieve Business Details

GetV1InstancesOnboardingBusinessProfileC

Retrieve Business Profile

GetV1InstancesOnboardingOwnershipDocumentsD

Retrieve Business Documents

GetV1InstancesByIdA

Returns the instance your API key or connection is bound to. Check type before moving money: development simulates settlement and moves no real funds, production moves real funds. onboarding_step is completed once the instance can transact.

PutV1InstancesByIdD

Update Instance

GetV1InstancesMembersC

Retrieve Instance Members

PutV1InstancesMembersByUserIdC

Update Instance Member Role

DeleteV1InstancesMembersByUserIdC

Delete Member from Instance

GetV1InstancesRfiB

Returns the open (pending) RFI for this instance, or null if the instance has no pending RFI.

PostV1InstancesRfiB

Submit a flat response object for the open instance RFI. Standalone: submitting does not change any instance or onboarding status. Returns { success: false, reason } when no pending RFI exists, callers should refetch the RFI state instead of retrying.

PostV1EInstancesTosA

Returns a URL where the end customer accepts BlindPay's terms of service. A person must open it in a browser and accept; it cannot be accepted through the API. After acceptance the browser is sent to redirect_url with tos_id as a query parameter, and a tos.accept webhook fires. Pass that tos_id (to_...) to Create Customer. idempotency_key is any unique string and cannot be reused.

GetV1InstancesCustomersLimitIncreaseC

Retrieve Limit Increase Requests

PostV1InstancesCustomersLimitIncreaseD

Request Limit Increase

GetV1InstancesCustomersD

Retrieve Customers

PostV1InstancesCustomersA

Creates a customer and starts KYC (individuals) or KYB (businesses). Send the tos_id the customer received after accepting terms of service (see Initiate Terms of Service). Required fields depend on type and kyc_type. Individual, standard: first_name, last_name, date_of_birth, tax_id, address_line_1, city, state_province_region, postal_code, country, id_doc_country, id_doc_type, id_doc_front_file and selfie_file. Business, standard: legal_name, formation_date, tax_id, website, the same address fields, at least one entry in owners, incorporation_doc_file, proof_of_ownership_doc_file, proof_of_address_doc_type and proof_of_address_doc_file. kyc_type light is not available, and businesses only support standard. US state_province_region is a two-letter code. File fields are HTTPS URLs that BlindPay downloads, so they must be publicly fetchable; data: URIs are rejected. The customer starts with kyc_status verifying. Development instances approve it automatically.

GetV1InstancesCustomersByIdC

Retrieve Customer

PutV1InstancesCustomersByIdC

Update Customer

DeleteV1InstancesCustomersByIdD

Delete Customer

GetV1InstancesLimitsCustomersByIdC

Retrieve Customer Limits

GetV1InstancesCustomersRfiA

Returns the open (pending) RFI for this customer, or null if the customer has no pending RFI.

PostV1InstancesCustomersRfiA

Submit a flat response object for the open RFI. On success flips kyc_status back to verifying. Returns { success: false, reason } when no pending RFI exists, callers should refetch the RFI state instead of retrying.

PostV1InstancesCustomersBankAccountsPlaidC

Create Plaid Link

GetV1InstancesCustomersBankAccountsC

Retrieve Bank Accounts

PostV1InstancesCustomersBankAccountsA

Adds a payout destination for a customer. Required fields depend on type (the rail): call Bank Details (GET /v1/available/bank-details) with the rail first for the exact field list and validation. For ach and wire: business_industry (a NAICS code from GET /v1/available/naics) is required when account_class is business, phone_number is required when country is BR, CN, CO, HK, MY, MX, PH, UG or UY, and tax_id is required when country is AR, BY, BR, CL, CN, CO, CR, EC, GT, HN, JP, KZ, KR, MX, PK, PE, PH, RU, TH or UY. A US state_province_region is a two-letter code. ach, wire and rtp are not available for light KYC customers.

GetV1InstancesCustomersBankAccountsByIdC

Retrieve Bank Account

DeleteV1InstancesCustomersBankAccountsByIdC

Remove Bank Account

GetV1InstancesCustomersVirtualAccountsC

Retrieve Virtual Accounts

PostV1InstancesCustomersVirtualAccountsB

Creates a virtual account that automatically converts inbound USD deposits (ACH, wire, RTP) into stablecoins sent to the linked wallet. Fees on these automated payins depend on the deposit amount: deposits below $100.00 accrue the BlindPay fee to your billing cycle (charged at the end of the month via the payin's billing_fee_amount), while deposits of $100.00 or more are charged at the time of the transaction (deducted from the delivered amount via transaction_fee_amount). Every deposit is processed regardless of size and always delivers at least $0.01 on-chain; a partner fee (optional partner_fee_id) is collected only from what remains after that.

GetV1InstancesCustomersVirtualAccountsByIdD

Retrieve Virtual Account

PutV1InstancesCustomersVirtualAccountsByIdD

Update Virtual Account

GetV1InstancesCustomersBlockchainWalletsSignMessageC

Retrieve Blockchain Wallet Message

GetV1InstancesCustomersBlockchainWalletsC

Retrieve Blockchain Wallets

PostV1InstancesCustomersBlockchainWalletsC

Add Blockchain Wallet

GetV1InstancesCustomersBlockchainWalletsByIdC

Retrieve Blockchain Wallet

DeleteV1InstancesCustomersBlockchainWalletsByIdC

Remove Blockchain Wallet

PatchV1InstancesCustomersBlockchainWalletsByIdA

Declares whether the customer holds the private keys of this wallet. Only works while is_self_custody is null; once saved it cannot be changed.

GetV1InstancesCustomersBankAccountsOfframpWalletsD

Get Offramp Wallets

PostV1InstancesCustomersBankAccountsOfframpWalletsC

Create Offramp Wallet

GetInstancesCustomersBankAccountsOfframpWalletsByIdD

Get Offramp Wallet

PostV1InstancesQuotesA

Prices a payout. Send exactly one of bank_account_id or payable_id. request_amount is in cents (1000 means 10.00) and currency_type says whether it is what the sender pays or what the receiver gets. The quote expires 5 minutes after creation (expires_at is epoch milliseconds) and is single-use: execute it with Create Payout on EVM Chains for BlindPay-managed wallets on any network, Solana included, or with the Solana or Stellar payout endpoints for self-custodied wallets.

PostV1InstancesQuotesFxD

Get FX Rate

GetV1InstancesPayoutsByIdD

Retrieve Payout

GetV1InstancesPayoutsC

Retrieve Payouts

PostV1InstancesPayoutsStellarAuthorizeD

Authorize Token Stellar

PostV1InstancesPayoutsStellarC

Create Payout on Stellar

PostV1InstancesPayoutsSolanaC

Create Payout on Solana

PostV1InstancesPayoutsEvmA

Executes a payout quote. Despite the name, this is the endpoint for payouts funded from a BlindPay-managed wallet on any network, Solana included; self-custodied EVM wallets must approve the token first. Execute before the quote expires (5 minutes). Send an Idempotency-Key header so a retry cannot create a second payout. On development instances the payout completes on its own; request_amount 66600 makes it fail and 77700 makes it refunded.

PostV1InstancesPayoutsDocumentsA

Submit a compliance document for a payout. SWIFT payouts waiting for documents require it and the submission resumes the compliance review; the optional payment description is written to the SWIFT memo. Other rails (wire, ACH, RTP, Pix and so on) may attach an optional document while the payout is processing or completed. It is stored for compliance without changing the payout status or tracking, the description is ignored, and submitting again replaces the previous document.

PostV1InstancesPayinQuotesA

Prices a payin from a local payment method into a stablecoin wallet. Send one of wallet_id (BlindPay-managed wallet) or blockchain_wallet_id. Do not send a network: the wallet decides where the tokens are delivered. request_amount is in cents; the minimum depends on the currency (1000, which is 10.00, for USD and BRL) and OTC quotes have a higher minimum. funding_bank_account_id is required when payment_method is ach_pull. The quote expires 5 minutes after creation, or 10 seconds for OTC quotes; create the payin with Create Payin before then.

PostV1InstancesPayinQuotesFxC

Get FX Rate

GetV1InstancesPayinsByIdC

Retrieve Payin

GetV1InstancesPayinsD

Retrieve Payins

PostV1InstancesPayinsEvmA

Creates a payin from a payin quote and returns the instructions the payer uses to send funds (for example a Pix code or bank details). Create it before the payin quote expires. Send an Idempotency-Key header so a retry cannot create a second payin. On development instances the payin completes on its own about 30 seconds after creation; request_amount 66600 makes it fail and 77700 makes it refunded.

PostV1InstancesPayinsCardPaymentC

Submit Card Payment

GetV1InstancesCustomersWalletsC

Retrieve Wallets

PostV1InstancesCustomersWalletsD

Create Wallet

GetV1InstancesCustomersWalletsByIdD

Retrieve Wallet

DeleteV1InstancesCustomersWalletsByIdC

Remove Wallet

GetV1InstancesCustomersWalletsBalanceB

Returns the balance of a BlindPay-managed wallet for USDC, USDT and USDB. Unlike quote and payout amounts, these values are whole tokens, not cents: amount 10.5 means 10.5 USDC. total_amount is amount plus earning_amount from yield.

GetV1InstancesCustomersWalletsDepositsC

Incoming stablecoin deposits to a managed wallet, newest first.

PostV1InstancesCustomersWalletsYieldEnableA

Turns yield on for the wallet. Returns the wallet, not the yield object: read yield_status here and use Retrieve Wallet Yield for positions. Idle balance is swept into the vault within the hour.

PostV1InstancesCustomersWalletsYieldDisableA

Turns yield off for the wallet. Returns the wallet, not the yield object. The wallet moves to disabling, the vault position is redeemed back to the wallet and any accrued fee is collected, then yield_status settles to disabled and a wallet.update webhook fires.

GetV1InstancesCustomersWalletsYieldHistoryC

Retrieve Wallet Yield History

GetV1InstancesCustomersWalletsYieldTransactionsC

Retrieve Wallet Yield Transactions

GetV1InstancesCustomersWalletsYieldC

Retrieve Wallet Yield

PostV1InstancesTransferQuotesD

Create Transfer Quote

GetV1InstancesTransfersByIdC

Retrieve Transfer

GetV1InstancesTransfersD

Retrieve Transfers

PostV1InstancesTransfersD

Create Transfer

GetV1InstancesPayablesD

List Payables

PostV1InstancesPayablesC

Create Payable

GetV1InstancesPayablesByIdD

Retrieve Payable

DeleteV1InstancesPayablesByIdC

Delete Payable

GetV1InstancesWebhookEndpointsC

Retrieve Webhooks

PostV1InstancesWebhookEndpointsA

Registers an HTTPS endpoint that receives the listed events. Event names and payload schemas are in the webhooks section of this API reference (and in the MCP resource blindpay://webhooks/events). Deliveries are signed with Svix; read the signing secret with Retrieve Webhook Secret and verify every delivery.

DeleteV1InstancesWebhookEndpointsByIdD

Remove Webhook

GetV1InstancesWebhookEndpointsSecretC

Retrieve Webhook Secret

GetV1InstancesWebhookEndpointsPortalAccessC

Retrieve Webhook Portal Access

GetV1InstancesBillingFeesB

Get all fees for an instance, sorted by payment method (fiat first, then blockchain)

GetV1InstancesPartnerFeesC

Retrieve Partner Fees

PostV1InstancesPartnerFeesD

Add Partner Fee

GetV1InstancesPartnerFeesByIdD

Retrieve Partner Fee

DeleteV1InstancesPartnerFeesByIdC

Remove Partner Fee

PostV1PresignD

Presign File URL

GetV1AvailableBankDetailsA

Returns the fields a bank account needs for a payout rail, so a recipient form can collect and validate them before calling create bank account. Each field has a label, the request body key to send it under, a validation regex, and, where the value comes from a fixed list (banks, countries, account types), the allowed items. Get valid rail values from GET /v1/available/rails. Public: no API key required.

GetV1AvailableRailsA

Lists every payout rail BlindPay supports (ACH, domestic wire, RTP, PIX, SPEI, SEPA, SWIFT, and more) as { label, value, country }. Pass value as the rail query parameter of GET /v1/available/bank-details, and as the type when creating a bank account. country is an ISO 3166-1 alpha-2 flag hint for display, not a statement of coverage. Public: no API key required.

GetV1AvailableNaicsC

NAICS list

GetV1AvailableSwiftBySwiftC

Swift code bank details

PostV1InstancesMintUsdbSolanaC

Mint USDB on Solana

PostV1InstancesPrepareDelegateSolanaB

Prepares a delegation transaction for Solana token transfers. You can either provide a quote_id (recommended) to automatically use the correct token amount and address from the quote, or manually provide owner_address, token_address, and amount.

PostV1InstancesCreateAssetTrustlineD

Create Asset Trustline

PostV1InstancesMintUsdbStellarC

Mint USDB on Stellar

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
webhook-eventsEvery webhook event BlindPay sends, with a link to each payload schema
webhook-event-bankAccount.newBank account created
webhook-event-blockchainWallet.newBlockchain wallet created
webhook-event-blockchainWallet.updateBlockchain wallet updated
webhook-event-customer.deleteCustomer deleted
webhook-event-customer.newCustomer created
webhook-event-customer.updateCustomer updated
webhook-event-limitIncrease.newLimit increase requested
webhook-event-limitIncrease.updateLimit increase updated
webhook-event-payable.completePayable paid
webhook-event-payable.newPayable registered
webhook-event-payable.updatePayable updated
webhook-event-payin.completePayin completed
webhook-event-payin.newPayin created
webhook-event-payin.partnerFeePayin partner fee
webhook-event-payin.updatePayin updated
webhook-event-payout.completePayout completed
webhook-event-payout.newPayout created
webhook-event-payout.partnerFeePayout partner fee
webhook-event-payout.updatePayout updated
webhook-event-tos.acceptTerms of service accepted
webhook-event-transfer.completeTransfer completed
webhook-event-transfer.newTransfer created
webhook-event-transfer.updateTransfer updated
webhook-event-virtualAccount.completeVirtual account complete
webhook-event-virtualAccount.newVirtual account created
webhook-event-wallet.inboundWallet inbound
webhook-event-wallet.newWallet created
webhook-event-wallet.updateWallet updated

TDQS

C2.3/5.0

Scored across 92 tools

Disambiguation3/5

The tools mostly map to distinct REST endpoints, and detailed descriptions help distinguish resources and actions. However, the set has many closely related variants such as payin/payout/transfer quotes, payin/payout execution endpoints across EVM/Solana/Stellar, and multiple wallet and bank-account subtypes, creating real selection ambiguity at scale.

Naming Consistency4/5

Names consistently follow an HTTP-method plus API-path convention, e.g. GetV1InstancesCustomers, PostV1InstancesPayinsEvm, DeleteV1InstancesWebhookEndpointsById. There are minor inconsistencies such as the odd `PostV1EInstancesTos` and `GetInstancesCustomersBankAccountsOfframpWalletsById` missing `V1`, but the overall pattern is predictable.

Tool Count1/5

92 tools is an extreme surface for an MCP server and far exceeds the typical 3-15 range. While the domain is broad, exposing nearly every REST endpoint as a separate tool makes discovery and correct selection unnecessarily difficult.

Completeness4/5

The surface covers the payment lifecycle broadly: customers, KYC/KYB, bank accounts, wallets, virtual accounts, payins, payouts, quotes, transfers, payables, webhooks, fees, onboarding, and compliance documents. There are minor gaps such as limited update/delete coverage for immutable payment objects, but no major dead ends for core workflows.

Maintenance

ActivityActive
ResponsivenessUnresponsive