PayFast MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. For example, refund.query checks availability, refund.create initiates a refund, and refund.fetch retrieves refund details, all serving different steps in the refund workflow. Similarly, subscription tools like pause, unpause, cancel, and update target specific lifecycle actions without overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with dot notation for subcategories (e.g., subscription.cancel, transaction.fetch). The naming is uniform across all 14 tools, using clear verbs like fetch, create, query, and cancel, making the set highly predictable and readable.
Tool Count5/5
With 14 tools, the count is well-scoped for a payment processing server, covering core operations like transactions, refunds, subscriptions, and connectivity. Each tool earns its place by addressing specific needs in the domain, such as subscription lifecycle management and transaction handling, without being excessive or sparse.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for the PayFast domain. It includes connectivity testing (ping), transaction processing and history (charge, fetch, history), refund management (query, create, fetch), and full subscription operations (fetch, update, pause, unpause, cancel, adhoc), with no obvious gaps that would hinder agent workflows.
Average 3.4/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 'Query' which suggests a read operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what the return format includes. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It lacks details on behavioral aspects (e.g., what data is returned, error handling) and usage context, making it inadequate for a tool that queries financial transaction details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the single parameter (pf_payment_id). The description adds no additional meaning beyond what the schema provides, such as format examples or usage context. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Query') and resource ('credit card transaction details'), with specific scope ('for a specific PayFast payment'). It distinguishes from siblings like transaction.fetch or transaction.history by focusing on credit card details for a single payment, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like transaction.fetch or refund.fetch is provided. The description implies it's for querying credit card details of a PayFast payment, but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the action ('return money to the customer's original payment method') but lacks critical details: whether this is reversible, what permissions are required, rate limits, error conditions, or what the response contains. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two clear sentences: one stating the action and one explaining the outcome. Every word earns its place, and it's front-loaded with the core purpose. No wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects (permissions, reversibility), response format, error handling, or business logic constraints. The 100% schema coverage helps with parameters, but overall completeness is poor for this tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'confirmed' and the refund process). 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create a refund') and resource ('for a PayFast transaction'), and distinguishes it from sibling tools like refund.fetch and refund.query by specifying it's for creation rather than retrieval. However, it doesn't explicitly differentiate from transaction.charge or other payment-related tools beyond the refund context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like refund.query or transaction.charge, nor does it mention prerequisites (e.g., needing a valid payment ID) or constraints (e.g., refund limits). It only states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it processes a charge without detailing behavioral traits. It doesn't mention whether this is a write operation, requires specific permissions, has side effects (e.g., billing the customer), rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficient. It doesn't explain what the tool returns, error conditions, or important behavioral context like whether the charge is immediate or pending. Given the complexity of financial operations, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the relationship between parameters or usage nuances. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Process') and resource ('ad-hoc charge on an existing PayFast subscription'), making the purpose evident. It distinguishes from siblings like subscription.cancel or transaction.charge by specifying it's for one-time charges on subscriptions, but doesn't explicitly contrast with transaction.charge which might also handle charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like transaction.charge or other subscription tools. The description implies it's for existing subscriptions, but doesn't state prerequisites, exclusions, or when to choose it over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fetches details but doesn't clarify if this is a read-only operation, what permissions are needed, how errors are handled, or the format of returned data. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly communicates the tool's function in a clear and structured manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 for a tool that likely returns subscription details. It doesn't address behavioral aspects like error handling or data format, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'token' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as explaining token format or sources. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch details') and resource ('PayFast subscription by its token'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'subscription.cancel' or 'subscription.update', which would require explicit comparison to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'subscription.adhoc' or 'transaction.fetch', nor are prerequisites or exclusions mentioned. The description assumes the user already knows when fetching subscription details is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 this is an update operation but doesn't mention critical behavioral aspects like whether it requires specific permissions, if changes are reversible, potential rate limits, or what happens to unspecified parameters. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing directly to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects, error conditions, return values, or how this tool relates to sibling subscription tools. The high schema coverage helps with parameters, but other contextual elements are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value by listing which parameters can be updated (amount, cycles, frequency, run date), but doesn't provide additional semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a PayFast subscription's parameters'), specifying the exact fields that can be modified (amount, cycles, frequency, or run date). However, it doesn't explicitly differentiate this tool from sibling subscription tools like subscription.adhoc or subscription.pause, which would require a more specific distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like subscription.adhoc or subscription.cancel. It lacks context about prerequisites (e.g., needing an active subscription) or exclusions (e.g., not for paused subscriptions), offering only a basic functional statement without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action ('fetch details') but lacks critical information: it doesn't specify if this is a read-only operation, what permissions are required, error handling, or the format of returned details. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a transaction fetch tool with no annotations and no output schema, the description is insufficient. It doesn't explain what details are returned, error cases, or behavioral traits like idempotency or rate limits, leaving the AI agent with incomplete context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'pf_payment_id' clearly documented. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('fetch') and resource ('details of a specific PayFast transaction'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'transaction.history' or 'refund.fetch', which might also retrieve transaction-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as needing a valid payment ID, or compare it to siblings like 'transaction.history' for broader queries or 'refund.fetch' for refund-specific details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it mentions the tool retrieves 'transaction history' and supports date range and pagination, it doesn't describe what the return format looks like, whether results are sorted, if there are rate limits, what authentication is required, or whether this is a read-only operation. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately communicates the core functionality. Every word earns its place: 'Get' establishes the action, 'PayFast transaction history' specifies the resource, and 'optional date range and pagination' highlights key capabilities. There's no wasted verbiage or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 4 well-documented parameters in the schema, the description provides adequate but minimal context. The lack of output schema means the description should ideally describe return values, but it doesn't. With no annotations to provide behavioral context and no output schema, the description leaves gaps about what the tool actually returns and under what conditions it operates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional date range and pagination' which maps to the from/to and offset/limit parameters respectively. However, with 100% schema description coverage where each parameter already has clear documentation in the schema, the description adds minimal value beyond what's already structured. The baseline score of 3 reflects adequate but not exceptional parameter guidance given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('PayFast transaction history'), making the purpose immediately understandable. It distinguishes this tool from siblings like transaction.charge (which creates transactions) and transaction.fetch (which likely retrieves a single transaction). However, it doesn't explicitly differentiate from refund.query or subscription.fetch, which might also retrieve historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional date range and pagination' which provides some context about when to use parameters, but offers no guidance on when to choose this tool versus alternatives like transaction.fetch (for single transactions) or refund.query (for refund history). There's no mention of prerequisites, authentication requirements, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action stops charges temporarily, but lacks details on permissions required, whether the pause is reversible, effects on subscription status, or any rate limits. This is a mutation tool with significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, zero waste. Every word earns its place by clarifying the tool's function and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on what happens after pausing (e.g., subscription state, confirmation requirements), error conditions, or return values, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying 'cycles' relates to billing cycles, which is already clear from the schema. Baseline 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('pause'), the resource ('PayFast subscription'), and the mechanism ('for a specified number of billing cycles'). It distinguishes from siblings like subscription.cancel (permanent) and subscription.unpause (resume).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('stops charges temporarily') but does not explicitly state when to use this versus alternatives like subscription.cancel or subscription.unpause. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that this 'creates a real payment', indicating a write operation with financial impact, and notes 'requires confirmation' as a behavioral constraint. However, it lacks details on permissions, rate limits, error handling, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. It front-loads the core purpose and follows with a critical constraint ('requires confirmation'), making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is minimal. It covers the basic action and a key constraint but lacks details on return values, error cases, or integration context. Given the complexity and financial nature, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('process a charge') and resource ('on a tokenized card'), specifying it 'creates a real payment'. It distinguishes from siblings like 'transaction.fetch' or 'refund.create' by focusing on charging. However, it doesn't explicitly differentiate from 'subscription.adhoc' which might also involve payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'requires confirmation', suggesting a prerequisite, but doesn't specify when to use this vs. alternatives like 'subscription.adhoc' or 'refund.create'. No explicit guidance on when-not-to-use or comparisons with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the billing impact ('Billing will resume on the next cycle'), which is valuable behavioral context. However, it doesn't mention permission requirements, error conditions, or what happens if the subscription isn't paused, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste—each sentence adds critical information. It's front-loaded with the core purpose and follows with behavioral impact, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 adequate but incomplete. It covers the action and billing effect but lacks details on permissions, response format, or error handling. Given the complexity, it should do more to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining the token format or why confirmation is needed. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Resume a previously paused PayFast subscription') and identifies the resource ('PayFast subscription'), distinguishing it from sibling tools like subscription.cancel or subscription.pause. It provides a complete picture of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'previously paused' subscription, which helps differentiate from subscription.adhoc or subscription.update. However, it doesn't explicitly state when NOT to use it or name alternatives, leaving some ambiguity about prerequisites or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's purpose (connectivity testing and credential verification) but doesn't mention behavioral aspects like whether it makes actual API calls, what happens on failure, response format, or any rate limits. It provides basic context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose without any unnecessary words. It's perfectly front-loaded and every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is reasonably complete for a connectivity test. However, it could benefit from mentioning what 'valid' credentials mean or what the expected response might be, especially since there's no output schema to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 the schema fully documents the absence of parameters. The description appropriately doesn't add parameter information beyond what the schema provides, which is correct for a no-parameter tool. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Test connectivity') and target resource ('PayFast API'), with the additional purpose of verifying credentials. It distinguishes itself from all sibling tools which perform financial operations like charges, refunds, and subscriptions, making this a unique connectivity verification tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need to test API connectivity or verify credentials. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the distinction from financial operations is clear from the tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that this is a query/check operation (not a mutation) and mentions return types (amounts, methods, parameters), which is helpful. However, it lacks details on error conditions, rate limits, authentication needs, or whether it has side effects. For a tool with no annotations, this leaves behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by return details and usage guidance. Every sentence earns its place: the first defines the action, the second specifies outputs, and the third provides critical workflow context. It's efficiently structured with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does a decent job for a simple query tool with one parameter. It explains the purpose, outputs, and usage context. However, it doesn't describe the return structure (e.g., JSON format) or error handling, which could be important for an agent. It's adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter 'pf_payment_id'. The description adds no additional parameter semantics beyond what's in the schema (e.g., format examples or constraints). With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Query refund availability') and resource ('for a transaction'), distinguishing it from sibling tools like 'refund.create' (which creates refunds) and 'refund.fetch' (which likely retrieves existing refunds). It explicitly mentions what information is returned ('available amounts, refund methods, required parameters'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('BEFORE creating a refund') and why ('to check if a refund is possible'). It distinguishes it from alternatives by implying this is a prerequisite step, with 'refund.create' as the logical next action. The instruction 'Use this first' clearly establishes its role in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical traits: the action is permanent ('cannot be undone'), which is essential for a destructive operation. However, it lacks details on permissions, rate limits, or error handling that would be helpful for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core action and its irreversible nature in a single sentence. Every word earns its place, with no wasted information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with no annotations and no output schema), the description is minimally adequate. It covers the permanence of the action but lacks details on success/error responses, side effects, or integration with other tools (e.g., refunds). This leaves gaps for an agent to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents both parameters (token and confirmed). The description does not add any meaning beyond what the schema provides, such as explaining the token format or the confirmation requirement's purpose. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('permanently cancel') and resource ('a PayFast subscription'), and distinguishes it from sibling tools like subscription.pause, subscription.unpause, and subscription.update by emphasizing the irreversible nature of cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to cancel a subscription permanently) and implies when not to use it (e.g., for temporary actions like pausing, as seen in sibling tools). However, it does not explicitly name alternatives or state prerequisites beyond the confirmation parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes the 404 error behavior when no refund exists, which is a critical behavioral trait. However, it doesn't mention other potential behaviors like rate limits, authentication requirements, or response format details, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with just two sentences that each earn their place. The first sentence states the purpose and scope, while the second provides critical behavioral guidance and workflow context. There's zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description does an excellent job covering the core functionality, error behavior, and workflow context. The main gap is the lack of information about the return format (what 'refund transaction history and available balance' actually looks like), which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 to get refund details for'. The description doesn't add any meaningful parameter semantics beyond what's already in the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('fetch refund transaction history and available balance') and resource ('for a payment that has ALREADY been refunded'), distinguishing it from sibling tools like refund.query (which checks availability) and refund.create (which initiates refunds). The phrase 'ALREADY been refunded' provides crucial context about the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use this tool ('for a payment that has ALREADY been refunded') and when not to use it ('Returns 404 if no refund exists yet'), plus it names an alternative tool to use first ('use refund.query first to check availability'). This gives clear guidance on the proper workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![payfast-mcp MCP server](https://glama.ai/mcp/servers/jpbester/payfast-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jpbester/payfast-mcp)

Score Badge

Copy to your README.md:

[![payfast-mcp MCP server](https://glama.ai/mcp/servers/jpbester/payfast-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jpbester/payfast-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jpbester/payfast-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server