This surface moves money — transfers, charges, stablecoin sends — and the server has a clean answer for that: name the tools you want registered and the rest do not exist for that client. A support workflow that only reads transactions never needs a transfer tool loaded. Two other things stand out. The card flow returns what to do next at each stage instead of failing on a mode the caller did not expect, which is what makes an assistant usable for it. And the BVN check requires a customer consent URL before any identity data comes back, which is the right shape for that data.
An MCP server over the Flutterwave API, covering the payment methods that matter in African markets rather than card alone. It handles the awkward parts properly: the multi-step card authorization dance, the request-quote-then-trade shape of FX, and the consent flow on identity verification.
- Hosted checkout links, created and disabled — `create_checkout`, `disable_checkout`
- Direct charges across the region's real payment rails: card, bank account for NGN and GHS, mobile money across Ghana, Uganda, Rwanda, Zambia and Francophone Africa, M-Pesa in KES, and USSD in NGN — `charge_card`, `charge_bank_account`, `charge_mobile_money`, `charge_mpesa`, `charge_ussd`
- The card authorization flow handled step by step rather than left to you — PIN, address verification, a 3D Secure redirect and OTP validation, with each response telling the assistant what the customer needs to supply next — `charge_card`, `validate_charge`
- Transaction lookup by id or by your own reference, the event timeline behind one, and a webhook resend when yours failed — `read_transaction`, `read_transaction_with_reference`, `read_transaction_timeline`, `resend_transaction_webhook`
- Payouts and recurring billing: bank transfers with saved beneficiaries, and subscription payment plans — `create_transfer`, `create_beneficiary`, `list_beneficiaries`, `create_payment_plan`, `get_payment_plans`
- Dedicated virtual account numbers for NGN and GHS bank-transfer collection, retrievable and updatable, with bulk batches listable — `create_virtual_account`, `get_virtual_account`, `update_virtual_account`, `list_virtual_account_bulk`
- Bill payments end to end for Nigeria — browse categories, providers and payable items, validate the customer's meter or smartcard number before charging, pay, then check status and collect prepaid electricity tokens — `get_bill_categories`, `get_bill_providers`, `get_bill_items`, `validate_bill_customer`, `pay_bill`, `get_bill_status`
- Currency conversion between NGN, GHS and USD as a proper two-step quote-then-trade, with polling on both — `request_fx_quote`, `get_fx_quote`, `initiate_fx_trade`, `get_fx_trade`
- Verification: BVN identity checks that issue a single-use customer consent URL before any data is returned, bank account name resolution, and card BIN lookup — `initiate_bvn_verification`, `get_bvn_details`, `resolve_bank_account`, `verify_card_bin`
- Stablecoin movement — check the fee and net amount first, then send USDC or USDT to a Polygon address, or convert an NGN or USD balance into one — `get_stablecoin_fee`, `send_stablecoin`, `convert_to_stablecoin`
- A branded HTML card rendered inline with every tool result in clients that support it
A Flutterwave account. `FLW_SECRET_KEY` is required; `FLW_ENCRYPTION_KEY` is additionally required for card charges, because card payloads are encrypted before they leave the server as PCI DSS requires — the encryption itself is handled for you once the variable is set. Node.js 20 or later for the npm and npx paths, or a published Docker image launched by your client with the keys passed as environment variables. Which tools are registered is controlled by a `--tools` argument: pass `all`, or a comma-separated list to expose only what you want. The package is `mcp-flutterwave` (1.4.1 in package.json) and it speaks stdio, so a client must launch it rather than it running standalone. It targets the Flutterwave v3 API.
One command plus a key — npx mcp-flutterwave --tools=all, then supply credentials