Click on "Deploy 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., "@PayFast MCP Check my current settlement balance"
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.
MCP server for PayFast payment gateway (South Africa).
Tool | Description |
| Create a payment request |
| Query transaction status |
| Cancel a subscription |
| Update a subscription |
| Charge tokenized card (ad-hoc) |
| Refund a payment |
| Get settlement balance |
| Validate a webhook signature |
Related MCP server: paymongo-mcp
{
"mcpServers": {
"payfast": {
"command": "npx",
"args": ["-y", "@theyahia/payfast-mcp"],
"env": {
"PAYFAST_MERCHANT_ID": "<YOUR_PAYFAST_MERCHANT_ID>",
"PAYFAST_MERCHANT_KEY": "<YOUR_PAYFAST_MERCHANT_KEY>",
"PAYFAST_PASSPHRASE": "<YOUR_PAYFAST_PASSPHRASE>"
}
}
}
}Variable | Required | Description |
| Yes | Merchant ID |
| Yes | Merchant key |
| Yes | API passphrase |
MIT
Cancel a subscription
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Subscription token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Cancel a subscription' implies a destructive mutation, but it doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., prorated refunds), or what happens upon success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in 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?
The description is extremely concise with a single sentence 'Cancel a subscription', which is front-loaded and wastes no words. Every word earns its place by directly stating the tool's purpose without redundancy or 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?
Given the tool's complexity (a destructive mutation with no annotations and no output schema), the description is incomplete. It lacks crucial details like behavioral traits (e.g., irreversibility, side effects), usage context, and expected outcomes. For a subscription cancellation tool, this minimal description leaves significant gaps for an AI agent to operate safely and effectively.
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 input schema has 100% description coverage, with the single parameter 'token' documented as 'Subscription token'. The description adds no additional meaning beyond this, such as explaining token format or where to obtain it. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Cancel a subscription' clearly states the action (cancel) and resource (subscription) with a specific verb. It distinguishes from siblings like 'update_subscription' by focusing on termination rather than modification. However, it doesn't explicitly differentiate from all siblings (e.g., 'refund_payment' might also relate to subscription cancellation scenarios).
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active subscription), exclusions (e.g., cannot cancel if already terminated), or relationships to sibling tools like 'update_subscription' for modifying instead of canceling. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Charge tokenized card (ad-hoc)
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Card token | |
| amount | Yes | Amount in cents | |
| item_name | Yes | Description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs a charge operation but provides no behavioral details about permissions required, whether this is reversible, rate limits, error conditions, or what happens after charging. For a financial transaction tool with zero annotation coverage, this is insufficient.
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 (5 words) with zero wasted words, though it may be too brief given the tool's complexity. It's front-loaded with the core action but lacks necessary elaboration for a financial transaction tool.
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 financial charging tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'ad-hoc' means, what the tool returns, error handling, or how it differs from sibling payment tools. The minimal description fails to compensate for the lack of structured metadata.
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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, maintaining the baseline score of 3 where schema does the heavy lifting.
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 states the action ('Charge') and resource ('tokenized card'), but is vague about scope and lacks sibling differentiation. It doesn't specify what 'ad-hoc' means operationally or how this differs from similar tools like 'create_payment' or 'refund_payment'.
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 alternatives. With siblings like 'create_payment' and 'refund_payment' available, the description offers no context about appropriate use cases, prerequisites, or exclusions for this specific charging method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a payment request
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in ZAR | |
| item_name | Yes | Item description | |
| email_address | Yes | Buyer email | |
| return_url | No | Return URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a payment request' implies a write operation but doesn't disclose important behavioral traits like authentication requirements, rate limits, whether this initiates an actual payment or just creates a request, what happens on failure, or any side effects. For a payment tool with zero annotation coverage, this is insufficient.
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 at just three words, front-loading the essential information with zero wasted words. Every word earns its place in communicating 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?
Given this is a payment creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation, what the response contains, error conditions, or how this differs from sibling tools. For a financial operation with potential real-world consequences, more context is needed.
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 description coverage is 100%, so the schema already documents all four parameters with their types and descriptions. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('Create') and resource ('payment request'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential siblings like 'create_adhoc' or 'refund_payment' that might also involve payment-related operations.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'create_adhoc', 'refund_payment', and 'update_subscription' available, there's no indication of when this specific payment creation tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get settlement balance
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get settlement balance' which implies a read operation, but doesn't disclose behavioral traits like whether this requires authentication, returns real-time or cached data, has rate limits, or what happens on errors. The description is minimal and lacks essential operational context.
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 'Get settlement balance' is extremely concise—just three words. It's front-loaded with the core action and resource. However, it might be overly terse, potentially sacrificing clarity for brevity, but it earns its place by stating the essential purpose without waste.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'settlement balance' entails (e.g., currency, time period, account scope) or what the return value looks like. For a tool with no structured context, more detail is needed to guide effective 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate given the schema completeness. The baseline for 0 parameters is 4, as there's nothing to compensate for.
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 'Get settlement balance' states a clear verb ('Get') and resource ('settlement balance'), but it's somewhat vague about what specifically is being retrieved. It doesn't differentiate from sibling tools like 'query_transaction' that might also provide financial data, leaving ambiguity about scope.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'query_transaction' that might return similar financial information, there's no indication of when this specific balance retrieval is appropriate or what distinguishes it from other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query transaction status
| Name | Required | Description | Default |
|---|---|---|---|
| pf_payment_id | Yes | PayFast payment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool queries status, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. This leaves significant gaps for an agent to understand the tool's behavior beyond basic purpose.
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 just two words ('Query transaction status'), which is front-loaded and wastes no space. Every word earns its place by conveying the core action and resource, making it efficient for quick understanding.
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 complexity of a transaction query tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'status' includes (e.g., success, pending, failed), the return format, or error handling. For a tool that likely returns critical payment information, this lack of context is inadequate.
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 input schema has 100% description coverage, with the single parameter 'pf_payment_id' clearly documented as 'PayFast payment ID'. The description adds no additional meaning beyond what the schema provides, such as format examples or context for the ID. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Query transaction status' clearly indicates the tool's function (querying) and resource (transaction status), but it's vague about what 'transaction status' entails. It distinguishes from siblings like 'create_payment' or 'refund_payment' by focusing on querying rather than modifying, but lacks specificity on what aspects of status are retrieved.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a payment ID), exclusions, or how it differs from other query-related tools like 'get_balance' or 'validate_signature'. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refund a payment
| Name | Required | Description | Default |
|---|---|---|---|
| pf_payment_id | Yes | Payment ID | |
| amount | No | Refund amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('refund') but doesn't explain critical behaviors: whether this is a partial or full refund by default, if it requires specific permissions, what happens on success/failure (e.g., funds reversal, status updates), or any rate limits. For a financial mutation tool, this is a significant gap in 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?
The description is extremely concise with just three words, front-loading the core action without any fluff. Every word ('refund', 'a', 'payment') earns its place by directly conveying the tool's purpose, making it efficient and easy to parse.
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 complexity of a financial refund operation, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, error handling), usage context, and expected outcomes. For a tool that modifies payments, this minimal description fails to provide the necessary context for safe and effective 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 description coverage is 100%, so the schema already documents both parameters ('pf_payment_id' and 'amount') adequately. The description doesn't add any meaning beyond this, such as explaining that 'amount' is optional for full refunds or detailing format constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 ('refund') and the resource ('a payment'), which is specific and unambiguous. However, it doesn't differentiate this tool from potential sibling tools like 'cancel_subscription' or 'query_transaction' that might also involve payment modifications, leaving room for confusion about when to choose this specific refund 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., payment must be in a refundable state), exclusions (e.g., cannot refund partially after a certain period), or relate it to sibling tools like 'cancel_subscription' for subscription-related refunds. This lack of context makes it hard for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a subscription
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Subscription token | |
| amount | No | New amount | |
| frequency | No | Frequency in months |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Update a subscription' implies a mutation operation but reveals nothing about permissions needed, whether changes are reversible, rate limits, error conditions, or what happens to unspecified subscription attributes. This leaves critical behavioral aspects undocumented.
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 at just three words, with zero wasted language. While this brevity comes at the cost of informativeness, it's structurally efficient and front-loaded, earning full marks for conciseness.
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 mutation tool with no annotations and no output schema, the description is severely inadequate. It doesn't explain what 'updating' entails, what values can be changed, what the expected outcome is, or how it differs from sibling operations. Given the complexity of subscription management, this leaves too many contextual gaps.
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 description coverage is 100%, with all three parameters ('token', 'amount', 'frequency') documented in the schema. The description adds no additional meaning about parameters beyond what the schema already provides, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 'Update a subscription' is essentially a tautology that restates the tool name 'update_subscription' without providing any meaningful elaboration. It doesn't specify what aspects of a subscription can be updated or what resources are involved, making it minimally informative beyond the obvious.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'cancel_subscription', 'create_payment', and 'refund_payment' available, there's no indication of when subscription updates are appropriate versus cancellation or payment modifications, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a webhook signature
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Webhook payload JSON | |
| signature | Yes | Signature from header |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but provides no information about what happens during validation - whether it returns a simple boolean, detailed validation results, error messages, or what happens on failure. For a security-critical validation tool, this lack of behavioral detail 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?
The description is perfectly concise - a single sentence that directly states the tool's function without any wasted words. It's front-loaded with the core purpose and contains no unnecessary elaboration or redundant information.
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 validation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes successful validation, what format the result takes, or how this tool integrates with the payment/subscription operations that dominate the sibling tools. The agent would be left guessing about the tool's behavior and integration context.
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 input schema has 100% description coverage, with both parameters clearly documented as 'Webhook payload JSON' and 'Signature from header'. The description doesn't add any additional semantic context beyond what the schema already provides, such as format requirements, encoding specifics, or examples of valid signatures. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('validate') and the target ('a webhook signature'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (which are all payment/subscription related), leaving some ambiguity about why this validation tool exists in this particular server context.
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 provides no guidance on when to use this tool versus alternatives. Given the sibling tools are all payment/subscription operations, there's no indication whether this validation is a prerequisite for those operations, a standalone security check, or something else entirely. No exclusions or contextual recommendations are provided.
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.
v1.0.1cancel_subscriptioncreate_adhoccreate_paymentget_balancequery_transactionrefund_paymentupdate_subscriptionvalidate_signatureScored across 8 tools
Each tool has a clearly distinct purpose targeting specific payment operations: subscription management (cancel, update), payment processing (create, refund, query), balance checking, ad-hoc charging, and webhook validation. No ambiguity exists between tools as they cover non-overlapping actions on different resources.
All tools follow a consistent verb_noun pattern with clear action verbs (cancel, create, get, query, refund, update, validate) paired with specific nouns (subscription, payment, balance, transaction, signature). The naming is uniform and predictable throughout the set.
With 8 tools, the server is well-scoped for a payment processing domain. Each tool earns its place by covering essential operations like payment lifecycle, subscription management, balance inquiries, and security validation without being overly sparse or bloated.
The toolset provides complete coverage for core payment workflows: payment creation, status querying, refunds, subscription management (cancel/update), balance checks, ad-hoc charges, and webhook validation. No obvious gaps exist for the inferred payment processing domain, supporting full agent interaction.
Remote MCP for ifthenpay payments: Multibanco, MB WAY and Payshop.
Self-facilitated x402/MCP payments for hosted endpoints, rail proofs, receipts, and agents.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
South African Reserve Bank (SARB) Web API MCP. Keyless.
