Uganda Payments (Flutterwave — MTN MoMo)
Server Details
Uganda payments for AI agents — MTN MoMo via Flutterwave. Never holds funds.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 3 of 3 tools scored.
Each tool has a unique purpose: creating a payment link, querying payment status, and refunding a payment. No functional overlap.
All tool names follow a consistent verb_noun pattern: create_payment_link, query_payment_status, refund_payment.
Three tools cover the essential operations for a payment link server—create, query, refund—without being excessive.
Covers the core payment lifecycle (create, monitor, refund). A cancel or list tool could be added, but the set is functional and not missing critical steps.
Available Tools
6 toolscancel_subscriptionADestructiveIdempotentInspect
Cancel a subscription so it will not renew. Requires the subscription_id, which you get from query_subscription (Flutterwave does not expose it at creation time — the buyer must complete the first payment, then query_subscription returns it).
| Name | Required | Description | Default |
|---|---|---|---|
| subscription_id | Yes | The subscription_id returned by query_subscription |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. Description adds that it 'will not renew', aligning with annotations but not adding significant behavioral detail beyond that. Adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. First sentence states purpose, second explains parameter source. Efficient and well-structured.
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 single parameter, no output schema, and annotations present, description provides all necessary context: what the tool does, prerequisite steps, and where to get the ID. No 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 coverage is 100% with subscription_id described. Description adds provenance info: 'which you get from query_subscription' and lifecycle context, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Cancel a subscription so it will not renew' – clear verb and resource. It also distinguishes from siblings by mentioning the need for subscription_id from query_subscription, which is unique among subscription tools.
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?
Explicitly states when to use (after first payment completed, subscription_id obtained from query_subscription). No explicit when-not-to-use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_payment_linkAInspect
Create a payment link in UGX for Uganda via Flutterwave. Buyer pays with MTN Mobile Money, Airtel Money, cards — via Flutterwave. Returns a hosted checkout URL the buyer opens to pay — payment completes automatically, no confirm step. Bring your own credentials via HTTP header (x-flutterwave-secret-key; free test credentials from dashboard.flutterwave.com never move real money). Money always flows buyer→Flutterwave→merchant; this service never touches funds.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_ugx | Yes | Amount in UGX (integer), e.g. 10000. Minimum 1000. | |
| description | Yes | What this payment is for (shown to the buyer, ≤200 chars) | |
| success_url | No | Optional https URL to send the buyer to after payment. | |
| reference_id | No | Your unique order reference (≤40 chars). Auto-generated if omitted. | |
| customer_email | Yes | Buyer email (required by Flutterwave; the receipt goes there). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by explaining automatic payment completion, no confirm step, and that the service never touches funds. Could mention rate limits or error handling, but sufficient for safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adds essential info: purpose, payment methods, automatic completion, credentials, money flow. No redundancy, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 params and no output schema, the description adequately explains the flow and return value. Could mention error responses or idempotency hints, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the return value (hosted checkout URL) and context like 'minimum 1000' for amount, which is also in schema but reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Create a payment link' and resource 'payment link' for Uganda via Flutterwave. Distinguishes from siblings (query_payment_status, refund_payment) which are about subsequent actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (to create a payment link) and provides context on credentials and money flow. Does not explicitly state when not to use, but siblings cover other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_subscription_linkAInspect
Create a recurring subscription checkout link (UGX, monthly/yearly/weekly billing) via Flutterwave. The buyer opens the URL, authorizes payment once, and is then charged automatically every period until canceled. Amount is per billing period. Respects the same owner policy guardrails as payments (the per-period amount is checked before anything is created).
| Name | Required | Description | Default |
|---|---|---|---|
| interval | No | Billing period. Default "month". | |
| amount_ugx | Yes | Amount charged per billing period (UGX major unit) | |
| description | Yes | What the subscription is for (also used as the Flutterwave plan name, <=80 chars) | |
| success_url | No | Optional https URL to send the buyer to after subscribing. | |
| customer_email | Yes | Buyer email (required by Flutterwave; receipts and renewal notices go there). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: explains buyer flow (authorize once, auto-charge), amount per period, and owner policy guardrails. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, and covers key points in four sentences. Slight redundancy but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers tool behavior and constraints well but omits return value (the checkout link) and error handling. Acceptable for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all parameters thoroughly (100% coverage). Description repeats some info but adds little new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes creating a recurring subscription checkout link for Flutterwave, clearly specifying the billing types (monthly/yearly/weekly) and the flow. Distinguishes from siblings like create_payment_link and cancel_subscription.
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?
Implicitly indicates use for recurring subscriptions, contrasting with one-time payment tools. Does not explicitly state when not to use or alternatives, but context is clear from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_payment_statusARead-onlyInspect
Check whether a Uganda payment (created by create_payment_link) has been paid. Queries Flutterwave directly — pull-based, no webhook needed. paid=true when status is PAID.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_ref | Yes | The tx_ref returned by create_payment_link |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds valuable context: queries Flutterwave directly, paid=true when status=PAID. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no redundant words. Purpose and behavior front-loaded. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, behavioral trait (pull-based), and output meaning (paid=true). No gaps given simple tool with one parameter and good annotations.
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?
Single parameter tx_ref with schema description already states it's returned by create_payment_link. Description doesn't add new meaning beyond what schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'check' and resource 'payment status', and specifies scope: Uganda payment from create_payment_link. Distinguishes from siblings by being the only status-check tool.
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?
States it's pull-based and queries Flutterwave directly, implying use case is to check status without a webhook. Doesn't explicitly list alternatives but context is clear given sibling tools are create and refund.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_subscriptionARead-onlyInspect
Check a subscription created by create_subscription_link. Query by customer_email (required); pass plan_id (returned at creation) to disambiguate when the same email has several plans. active=true when the subscription status is ACTIVE; NOT_SUBSCRIBED_YET means the buyer has not completed the first payment yet. The result includes subscription_id — keep it to cancel later.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | No | Optional plan_id returned by create_subscription_link (disambiguates multiple subscriptions on the same email). | |
| customer_email | Yes | The buyer email used in create_subscription_link |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that active=true corresponds to ACTIVE status and explains the NOT_SUBSCRIBED_YET state. Mentions the output includes subscription_id. Annotations indicate readOnlyHint=true, which is consistent. The description adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet informative, providing essential details in two sentences. It front-loads the purpose and uses clear language. Slight room for improvement by breaking into bullet points for scanability.
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 no output schema, the description partially explains return fields (active, subscription_id) and status values. It covers key aspects for using the tool effectively, though a full list of output fields would enhance completeness.
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?
Both parameters are already described in the schema (100% coverage). The description reinforces that customer_email is required and explains how plan_id disambiguates multiple subscriptions, adding context beyond the schema definitions.
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 explicitly states 'Check a subscription created by create_subscription_link', which clearly identifies the tool's purpose as querying subscription status. It distinguishes from sibling tools like cancel_subscription and create_subscription_link by focusing on status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: after creating a subscription link. Offers disambiguation advice with plan_id and mentions keeping subscription_id for cancellation. However, does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refund_paymentADestructiveInspect
Refund a paid payment (created by create_payment_link). Full refund by default; pass amount for a partial refund where supported. Refunds respect the same owner policy guardrails (x-agentpay-max-amount) as payments — the amount is checked before anything is sent to the gateway.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Optional partial-refund amount in the local currency major unit. Omit for a full refund. | |
| tx_ref | Yes | The tx_ref of the paid payment (same id used by query_payment_status) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description adds valuable behavioral context: that refunds respect the same owner policy guardrails as payments, that the amount is checked before gateway processing, and that partial refunds are only supported where the gateway allows it. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the primary purpose and context, followed by succinct detail about partial refunds and guardrails. No extraneous information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains input behavior and constraints for a destructive tool without output schema. It could benefit from mentioning response structure (e.g., success indicator or refund ID) but is otherwise complete given the tool's simplicity.
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?
With 100% schema coverage, the description enhances meaning by clarifying the default behavior (full refund vs. partial) and adding nuance ('where supported') for the amount parameter. It also ties the amount parameter to the guardrail check, adding context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Refund a paid payment') and identifies the specific resource scope ('created by create_payment_link'), distinguishing it from sibling tools like create_payment_link and query_payment_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on default full refund vs. partial refund by passing amount, and mentions policy guardrails. However, it does not explicitly state when not to use this tool or mention alternative tools, though siblings are clearly different in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!