PayFast MCP

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 2.8/5 across 8 of 8 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 status not available
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 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.
Conciseness5/5
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.
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 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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/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. 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.
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 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.
Conciseness4/5
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.
Completeness2/5
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.
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 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.
Purpose3/5
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.
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. 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.
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 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.
Conciseness5/5
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.
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 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.
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'. 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.
Purpose3/5
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.
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 (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.
Behavior2/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 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.
Conciseness4/5
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.
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. 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.
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 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.
Purpose3/5
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.
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. 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.
Behavior2/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 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.
Conciseness5/5
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.
Completeness2/5
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.
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 '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.
Purpose4/5
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.
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 (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.
Behavior2/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 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.
Conciseness5/5
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.
Completeness2/5
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.
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 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.
Purpose4/5
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.
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. 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.
Behavior2/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 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.
Conciseness5/5
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.
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 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.
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 ('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.
Purpose4/5
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.
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 (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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
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 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.
Purpose4/5
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.
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. 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.

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/theYahia/payfast-mcp/badges/card.svg)](https://glama.ai/mcp/servers/theYahia/payfast-mcp)

Score Badge

Copy to your README.md:

[![payfast-mcp MCP server](https://glama.ai/mcp/servers/theYahia/payfast-mcp/badges/score.svg)](https://glama.ai/mcp/servers/theYahia/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/theYahia/payfast-mcp'

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