South Africa Payments (Paystack — cards / EFT)
Server Details
South Africa payments for AI agents — cards / EFT via Paystack. Never holds funds.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 2 of 2 tools scored.
Both tools have clearly distinct purposes: one creates a payment link, the other queries its status. There is no functional overlap or ambiguity.
Both tools follow a consistent verb_noun pattern (create_payment_link and query_payment_status), which is predictable and clear.
With only two tools for a payment domain, the server is somewhat thin but covers the essential create-and-check workflow. Additional tools like refund or cancel would be expected for full functionality, but the count is not extreme.
The server provides the core flow of creating a payment and checking status, but lacks important operations like refunds, cancellations, or webhook handling. This leaves notable gaps for real-world payment workflows.
Available Tools
6 toolscancel_subscriptionADestructiveIdempotentInspect
Cancel (disable) a subscription so it will not renew. Pass the subscription_code (SUB_...) from query_subscription; email_token is resolved automatically if omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| email_token | No | Optional email_token from query_subscription; auto-resolved when omitted. | |
| subscription_code | Yes | The subscription_code (SUB_...) returned by query_subscription |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. Description adds 'will not renew' but doesn't detail side effects, auth needs, or what happens to the current period. Adds minimal value beyond annotations.
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 concise sentences, front-loaded with action and effect. No unnecessary words, 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?
No output schema, but side-effect operation is adequately described. Could mention that subscription remains active until end of current period, but otherwise complete for an agent to understand.
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 coverage is 100%, and description adds context: subscription_code from query_subscription, email_token auto-resolved. Provides meaning beyond the schema fields.
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 the action (cancel/disable), the resource (subscription), and the effect (will not renew). It distinguishes from siblings like create_subscription_link or query_subscription by specifying the cancellation operation.
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?
Provides clear instructions to pass subscription_code from query_subscription and that email_token is optional. Lacks explicit 'when not to use' or alternatives, but the context with sibling tools implies use for cancellation only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_payment_linkAInspect
Create a payment link in ZAR for South Africa via Paystack. Buyer pays with cards, instant EFT, and other methods via Paystack. Returns a hosted checkout URL the buyer opens to pay — payment completes automatically, no confirm step. Bring your own credentials via HTTP header (x-paystack-secret-key; free test credentials from dashboard.paystack.com never move real money). Money always flows buyer→Paystack→merchant; this service never touches funds.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_zar | Yes | Amount in ZAR (decimals allowed), e.g. 10. Minimum 1. | |
| description | Yes | What this payment is for (shown to the buyer, ≤200 chars) | |
| success_url | No | Optional https URL to send the buyer to after payment. | |
| reference_id | No | Your unique order reference (≤40 chars). Auto-generated if omitted. | |
| customer_email | Yes | Buyer email (required by Paystack; the receipt goes there). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the flow of funds, automatic payment completion, no confirm step, and authentication method (x-paystack-secret-key). Adds significant context beyond annotations, which only indicate non-read-only, open world, non-idempotent, non-destructive.
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?
Four focused sentences with no wasted words. Purpose first, followed by details, then behavioral notes. Excellent structure.
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?
Covers purpose, parameters, behavior, and credentials. Without output schema, it still explains the return value (hosted checkout URL). Could mention error handling but overall adequate.
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 coverage is 100%, giving a baseline of 3. The description enhances each parameter with examples and additional details (e.g., amount minimum, description character limit, reference ID auto-generation).
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?
Clearly states 'Create a payment link in ZAR for South Africa via Paystack', specifying verb, resource, region, and payment processor. Distinguishes from sibling tool 'query_payment_status' by focusing on creation.
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?
Explains when to use (create payment link) and mentions credentials requirement. Sibling tool is named but not explicitly contrasted; however, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_subscription_linkAInspect
Create a recurring subscription checkout link (ZAR, monthly/yearly/weekly billing) via Paystack. The buyer opens the URL, authorizes their card once, and is then charged automatically every period until canceled. Amount is per billing period. Respects the same owner policy guardrails as payments (the per-period amount is checked before anything is created).
| Name | Required | Description | Default |
|---|---|---|---|
| interval | No | Billing period. Default "month". | |
| amount_zar | Yes | Amount charged per billing period (ZAR major unit) | |
| description | Yes | What the subscription is for (also used as the Paystack plan name, <=80 chars) | |
| success_url | No | Optional https URL to send the buyer to after subscribing. | |
| customer_email | Yes | Buyer email (required by Paystack; receipts and renewal notices go there). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a write operation. Description adds details on automatic recurring charges, card authorization, and policy checks. No contradictory information.
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?
Concise two-sentence description. First sentence states primary purpose, second provides flow details. No unnecessary words.
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?
Covers main behavior, billing model, and policy. Lacks return value specification (likely a URL) but acceptable for a creation tool.
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 covers all parameters with descriptions. Description adds valuable context: amount is per period, description is Paystack plan name with char limit, customer_email for receipts. Clarifies beyond schema.
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 creates a recurring subscription checkout link via Paystack with specific currency and billing intervals. It distinguishes from sibling tools like create_payment_link by focusing on recurring billing.
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?
Describes the recurring payment flow and mentions policy guardrails. Implicitly informs when to use (recurring billing) but does not explicitly contrast with one-time payment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_payment_statusARead-onlyInspect
Check whether a South Africa payment (created by create_payment_link) has been paid. Queries Paystack directly — pull-based, no webhook needed. paid=true when status is PAID.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | The reference returned by create_payment_link |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by specifying 'pull-based, no webhook needed' and explaining the paid=true condition based on status, which is beyond annotations.
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 extremely concise with two sentences, no unnecessary words, and front-loads the core purpose.
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?
For a simple query with one parameter, no output schema, and good annotations, the description covers the essential behavior and linkage to sibling tool. It could mention error responses but is adequate.
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 schema has 100% coverage with the description of reference. The tool description repeats that reference is from create_payment_link, which aligns with the schema but does not add new meaning beyond what the schema already provides.
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 the tool checks payment status for South Africa payments created by a sibling tool, with a specific verb 'Check' and resource 'payment status'. It distinguishes itself from alternatives by specifying pull-based behavior.
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?
The description mentions it queries Paystack directly (pull-based) and is for payments from create_payment_link, implying when to use. It does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_subscriptionARead-onlyInspect
Check a subscription created by create_subscription_link, using the reference returned at creation. active=true when the subscription is ACTIVE; NOT_SUBSCRIBED_YET means the buyer has not completed checkout. The result includes subscription_code and email_token — keep them to cancel later.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | The reference returned by create_subscription_link |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark safe read; description adds useful context about status meanings and returned tokens for cancellation, enhancing transparency.
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 concise sentences, front-loaded with purpose, no fluff.
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?
Complete for a simple tool: explains input, output fields (status, tokens), and connection to creation, compensating for lack of output schema.
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 already fully documents the single parameter with a description; the description reinforces usage but adds no new semantic details.
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 it checks a subscription created by create_subscription_link using the reference, and distinguishes from siblings like cancel_subscription and query_payment_status.
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?
Specifies to use the reference from creation and explains the meaning of status values, but does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refund_paymentADestructiveInspect
Refund a paid payment (created by create_payment_link). Full refund by default; pass amount for a partial refund where supported. Refunds respect the same owner policy guardrails (x-agentpay-max-amount) as payments — the amount is checked before anything is sent to the gateway.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Optional partial-refund amount in the local currency major unit. Omit for a full refund. | |
| reference | Yes | The reference of the paid payment (same id used by query_payment_status) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true. The description confirms a refund operation, which is destructive, and adds detail about the guardrail check before gateway submission. This goes beyond the annotation, but could mention idempotency or side effects.
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?
Three succinct sentences: first states purpose, second explains full/partial refund, third adds guardrails. No redundant information, front-loaded with the core action.
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?
For a 2-parameter tool with no output schema, the description covers key behaviors: default full refund, partial refund option, and guardrail enforcement. It doesn't specify return values or error handling, but is adequate for an AI agent to use correctly.
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 coverage is 100%, but the description adds value by explaining that 'amount' is optional for partial refunds and that 'reference' is the same ID used by query_payment_status, linking to a sibling tool.
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 the purpose: 'Refund a paid payment (created by create_payment_link).' It specifies the action (refund) and the resource (paid payment), and the context differentiates it from sibling tools (create_payment_link, query_payment_status).
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?
The description explains default behavior ('Full refund by default') and optional parameter for partial refunds. It also mentions guardrails ('x-agentpay-max-amount') and that the amount is checked before processing. While it doesn't explicitly state when not to use, it provides sufficient context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!