Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@paystack-mcp-server show my last 5 transactions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to interact with the full range of Paystack APIs.
Public Preview: This MCP server is currently in public preview. We're seeking early feedback to improve the next iteration, so use cautiously and report any issues you encounter.
Install and run via npm (recommended):
npx @paystack/mcp-server --api-key sk_test_your_key_hereOr for local development, clone and build:
git clone https://github.com/PaystackOSS/paystack-mcp-server.git
cd paystack-mcp-server
npm install
npm run buildThen configure your MCP client to use the server (see Client Integration).
Related MCP server: PayBridgeNP MCP Server
Node.js v18+
npm or yarn
A Paystack test secret key (starts with sk_test_)
Environment Variable | Purpose |
| Your Paystack test secret key (fallback if no CLI arg) |
You can provide your API key in two ways:
CLI argument (recommended): --api-key sk_test_...
Environment variable: Set PAYSTACK_TEST_SECRET_KEY
Security note: Only test keys (
sk_test_*) are allowed. The server validates this at startup and will reject live keys.
The Paystack MCP Server works with any MCP-compatible client. Below is the standard configuration schema used by most clients (Claude Desktop, ChatGPT Desktop, Cursor, Windsurf, etc.).
For npm-installed server:
{
"mcpServers": {
"paystack": {
"command": "npx",
"args": ["@paystack/mcp-server", "--api-key", "sk_test_..."]
}
}
}If you've cloned and built the server locally:
{
"mcpServers": {
"paystack": {
"command": "node",
"args": ["/path/to/paystack-mcp-server/build/index.js"],
"env": {
"PAYSTACK_TEST_SECRET_KEY": "sk_test_..."
}
}
}
}When settingcommand: "node", you should ensure you're using Node v18+. If you are using a package manager, you might need to get the path of your Node binary by running this command in your CLI:
which nodewhere nodeOnce you have the path, use it as the value of the MCP Server command in the JSON configuration. e.g., command: "path/to/installation/bin/node"
Client | Config file location |
VS Code |
|
Claude Desktop |
|
ChatGPT Desktop | MCP settings in app preferences |
Cursor |
|
Windsurf | MCP configuration in settings |
Claude Code |
|
The Paystack MCP Server exposes the entire Paystack API to AI assistants by parsing Paystack's OpenAPI specification at runtime. Instead of hardcoding individual endpoints, the server dynamically discovers all available operations and makes them accessible through a small set of tools.
Tool | Description |
| Fetch operation details (method, path, parameters) by operation ID |
| Execute a Paystack API request |
Resource | URI | Description |
|
| List all available Paystack operations and their details |
When you ask your AI assistant something like "Get me the last 5 transactions on my Paystack integration", here's what happens behind the scenes:
The assistant calls get_paystack_operation("transaction_list") to look up the endpoint details
It gets back the method (GET), path (/transaction), and available query parameters
It then calls make_paystack_request with { method: "GET", path: "/transaction", data: { perPage: 5 } }
You get your transactions
To get the best results when using this MCP server, be specific in your prompts and always include "Paystack" in your requests. The server provides built-in instructions and a knowledge resource (paystack://skill) that help the AI assistant find the right documentation, code snippets, and API details.
Good prompts:
"Initialize a Paystack transaction for 50000 NGN"
"Create a customer with email user@example.com on my Paystack account"
"How can I send money with the Paystack API?"
"Show me a cURL example for verifying a Paystack transaction"
Less effective prompts:
"List my transactions" (unclear which service to use)
"Charge a customer" (missing context about Paystack)
Being explicit ensures the LLM narrows down to the right tool quickly and reduces ambiguity.
For local development and testing, you can run the TypeScript source directly:
PAYSTACK_TEST_SECRET_KEY=sk_test_... npm run devnpm run inspectnpm run buildnpm testIssue | Solution |
Server exits silently at startup | Check that |
"Invalid key" error | Key must start with |
Tools not appearing in client | Ensure the server is running and the client config path is correct |
Request timeouts | Check network connectivity to |
Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.
See CONTRIBUTING.md for more details.
MIT
Get Paystack API operation details by operation ID. Available operations are: transaction_initialize, transaction_chargeAuthorization, transaction_partialDebit, transaction_verify, transaction_list, transaction_fetch, transaction_timeline, transaction_totals, transaction_export, charge_create, charge_submitPin, charge_submitOtp, charge_submitPhone, charge_submitBirthday, charge_submitAddress, charge_check, bulkCharge_initiate, bulkCharge_list, bulkCharge_fetch, bulkCharge_charges, bulkCharge_pause, bulkCharge_resume, subaccount_create, subaccount_list, subaccount_fetch, subaccount_update, split_create, split_list, split_fetch, split_update, split_addSubaccount, split_removeSubaccount, terminal_sendEvent, terminal_fetchEventStatus, terminal_fetchTerminalStatus, terminal_list, terminal_fetch, terminal_update, terminal_commission, terminal_decommission, virtualTerminal_create, virtualTerminal_list, virtualTerminal_fetch, virtualTerminal_update, virtualTerminal_deactivate, virtualTerminal_destinationAssign, virtualTerminal_destinationUnassign, virtualTerminal_addSplitCode, virtualTerminal_deleteSplitCode, customer_create, customer_list, customer_fetch, customer_update, customer_riskAction, customer_validate, customer_initializeAuthorization, customer_verifyAuthorization, customer_deactivateAuthorization, customer_initializeDirectDebit, customer_directDebitActivationCharge, customer_fetchMandateAuthorizations, directdebit_triggerActivationCharge, directdebit_listMandateAuthorizations, dedicatedAccount_create, dedicatedAccount_list, dedicatedAccount_assign, dedicatedAccount_fetch, dedicatedAccount_deactivate, dedicatedAccount_requery, dedicatedAccount_addSplit, dedicatedAccount_removeSplit, dedicatedAccount_availableProviders, applePay_registerDomain, applePay_listDomain, applePay_unregisterDomain, plan_create, plan_list, plan_fetch, plan_update, subscription_create, subscription_list, subscription_fetch, subscription_disable, subscription_enable, subscription_manageLink, subscription_manageEmail, transferrecipient_create, transferrecipient_list, transferrecipient_bulk, transferrecipient_fetch, transferrecipient_update, transferrecipient_delete, transfer_initiate, transfer_list, transfer_finalize, transfer_bulk, transfer_fetch, transfer_verify, transfer_exportTransfer, transfer_resendOtp, transfer_disableOtp, transfer_disableOtpFinalize, transfer_enableOtp, balance_fetch, balance_ledger, paymentRequest_create, paymentRequest_list, paymentRequest_fetch, paymentRequest_update, paymentRequest_verify, paymentRequest_notify, paymentRequest_totals, paymentRequest_finalize, paymentRequest_archive, product_create, product_list, product_fetch, product_update, product_delete, storefront_create, storefront_list, storefront_fetch, storefront_update, storefront_delete, storefront_verifySlug, storefront_fetchOrders, storefront_addProducts, storefront_listProducts, storefront_publish, storefront_duplicate, order_create, order_list, order_fetch, order_product, order_validate, page_create, page_list, page_fetch, page_update, page_checkSlugAvailability, page_addProducts, settlements_fetch, settlements_transaction, integration_fetchPaymentSessionTimeout, integration_updatePaymentSessionTimeout, refund_create, refund_list, refund_retry, refund_fetch, dispute_list, dispute_fetch, dispute_update, dispute_uploadUrl, dispute_download, dispute_transaction, dispute_resolve, dispute_evidence, bank_list, bank_resolveAccountNumber, bank_validateAccountNumber, miscellaneous_resolveCardBin, miscellaneous_listCountries, miscellaneous_avs
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes | The operation ID of the Paystack API endpoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies read-only behavior ('Get'), but it does not explicitly state that this operation is non-destructive or what side effects it might have. Annotations provide no additional behavioral hints (e.g., readOnlyHint, destructiveHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and includes a necessary list. While the list is lengthy, it is essential. The description is otherwise concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the many available operations and the lack of an output schema, the description adequately covers the input domain but does not describe the output format or what 'operation details' includes. This leaves ambiguity about the tool's return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value by enumerating all valid operation IDs (over 100 entries), which the input schema schema only describes as 'the operation ID of the Paystack API endpoint'. This enumeration is crucial for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Get Paystack API operation details by operation ID.' The verb 'get' and resource 'operation details' are specific. However, it does not explicitly differentiate from the sibling tool 'make_paystack_request', which could cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling tool 'make_paystack_request'. The description only lists available operation IDs without contextualizing the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a Paystack API request using the details of the operation. Be sure to get all operation details including method, path path parameters, query parameters, and request body before making a call.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (readOnly/destructive), and the description does not mention side effects, auth requirements, or response behavior. For a tool that can make arbitrary HTTP requests, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives usage instruction. No fluff, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a generic HTTP client with complex nested parameters and no output schema, the description omits key details like expected return value, error handling, base URL, and authentication context. More context is needed for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters, but the description adds context by listing 'method, path path parameters, query parameters, and request body'. However, it does not explain the 'request' wrapper or 'data' structure fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function as 'Make a Paystack API request', distinguishing it from the sibling tool 'get_paystack_operation' which likely retrieves operation details. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description advises to 'get all operation details' before making a call, implicitly recommending use of the sibling tool. This provides clear usage context for the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.2get_paystack_operationmake_paystack_requestThe two tools have clearly distinct purposes: one retrieves details about a Paystack API operation, the other executes the actual request. No overlap in functionality.
Both tool names follow a consistent verb_noun pattern: get_paystack_operation and make_paystack_request, making them predictable and easy to use.
With only 2 tools, the server feels thin for a full Paystack API wrapper. However, the generic design allows coverage of many operations, but 2 is borderline for typical MCP servers.
The tool set covers all Paystack operations listed in the get_paystack_operation description. The discovery-and-execute pattern ensures no missing functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nigeria payments for AI agents — bank transfer / USSD via Paystack. Never holds funds.
South Africa payments for AI agents — cards / EFT via Paystack. Never holds funds.
Ghana payments for AI agents — MTN MoMo via Paystack. Never holds funds.
Let AI agents add Yolfi crypto checkout, paylinks, webhooks, and status checks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaystackOSS/paystack-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
