Rwanda Payments (Flutterwave — MTN MoMo)
Server Details
Rwanda 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 clear, distinct purpose: creating a payment link, querying payment status, and issuing refunds. There is no overlap or ambiguity.
All tool names follow the verb_noun pattern (create_payment_link, query_payment_status, refund_payment), ensuring predictability and ease of use.
With 3 tools, the server is minimal but well-scoped for its targeted purpose of Rwanda payments. It could benefit from additional tools like listing payments, but the current count is reasonable.
The tool set covers the essential lifecycle: create, query, refund. Minor gaps like canceling pending payments or listing transactions exist but do not hinder core functionality.
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 idempotentHint=true. The description adds value by explaining the preconditions (needs subscription_id from query_subscription) and the effect (prevents renewal), but does not introduce behavioral contradictions. It reinforces the tool's safety profile without conflicting with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover the tool's purpose, behavior, and usage guidance without any unnecessary words or repetition. Every sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is complete. It covers the action, prerequisite, source of the parameter, and the effect, making it fully self-contained.
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 a clear description for subscription_id. The description repeats this but adds critical context about where the ID comes from and why it's needed, enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel a subscription') and the result ('so it will not renew'). It effectively distinguishes from siblings like query_subscription by indicating that this tool is for cancellation, not querying.
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 context for when to use the tool (to cancel a subscription) and includes a crucial prerequisite: the subscription_id must be obtained from query_subscription after the first payment. It also explains why the ID is not available at creation time, preventing misuse.
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 RWF for Rwanda 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_rwf | Yes | Amount in RWF (integer), e.g. 5000. Minimum 500. | |
| 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?
The description adds significant behavioral context beyond annotations: it mentions the need for a Flutterwave secret key via HTTP header, the automatic completion of payment, and that the service never touches funds. This clearly informs the agent of the tool's external dependencies and transactional nature.
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 three sentences, front-loaded with the core action, then outcome, then credential/money-flow context. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and moderate complexity, the description adequately covers the return value (hosted checkout URL), the payment flow, credential requirements, and money handling. It is complete for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 5 parameters with descriptions, so baseline is 3. The description does not add extra parameter-specific semantics beyond what the schema provides, but it contextualizes the parameters within the payment flow (e.g., RWF currency, customer email for receipt).
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 creates a payment link in RWF for Rwanda via Flutterwave, specifying payment methods and that it returns a hosted checkout URL. It distinguishes from sibling tools like query_payment_status and refund_payment, which deal with existing payments.
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 implies the tool is for initiating a new payment by creating a payment link. However, it does not explicitly state when to use this tool versus alternatives like query_payment_status or refund_payment. Usage is implied but not explicitly guided.
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 (RWF, 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_rwf | Yes | Amount charged per billing period (RWF 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?
Annotations indicate non-idempotent, non-destructive write. Description adds context: buyer authorizes once, auto-charged, guardrails check amount before creation. Does not describe return value (likely a URL) but provides enough behavioral detail 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?
Three concise sentences front-load the purpose and flow. Every sentence adds value with no redundancy.
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?
Description covers purpose, flow, and guardrails but omits return value format (e.g., checkout URL) and prerequisites. With 5 parameters, no output schema, and moderate complexity, more detail on outputs would improve 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?
Schema covers all 5 parameters with descriptions (100% coverage). Description reiterates 'Amount is per billing period' but adds no new parameter-specific meaning beyond the schema. Baseline 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?
The description clearly states the tool creates a recurring subscription checkout link via Flutterwave, specifying currency (RWF) and billing frequencies. It explains the buyer flow, distinguishing it from one-time payment links (sibling 'create_payment_link').
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 implies use for recurring billing vs one-time payments but does not explicitly state when to use this tool vs alternatives like create_payment_link or cancel_subscription. Lacks explicit when-not or alternative naming.
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 Rwanda 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=true (read operation) and openWorldHint=true (dynamic responses). The description adds specific behavioral details: queries Flutterwave directly, pull-based model, and the condition for paid=true. 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 concise sentences that front-load the key purpose and behavior. Every word contributes value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains the meaning of paid=true. It covers the core use case. Could mention possible other statuses, but for a simple status check it's sufficient.
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% (one parameter tx_ref described as returned by create_payment_link). The description reiterates that tx_ref comes from that function, adding slight value but not deeply elaborating on format or constraints. Baseline 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?
The description clearly states the tool's purpose: checking if a Rwanda payment created by create_payment_link has been paid. It specifies pull-based querying (no webhook) and the condition for paid=true when status=PAID. This distinguishes it from siblings like create_payment_link and refund_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (after creating a payment link, for pull-based status checks) and that it is not webhook-dependent. It could be more explicit about when not to use (e.g., for non-Rwanda payments) but provides clear context.
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?
Beyond annotations (readOnlyHint, openWorldHint), the description adds meaningful context: explains the status values (active=true, NOT_SUBSCRIBED_YET) and that the result includes subscription_id for later cancellation.
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 sentences, each serving a clear purpose: stating overall function, parameter guidance, and output interpretation. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains key return values (status, subscription_id). Could be slightly more comprehensive about other possible fields, but sufficient for the main use case.
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 parameters are already documented. The description reinforces that customer_email is required and plan_id is optional, adding the helpful context that plan_id is returned at creation time.
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 it checks a subscription created by create_subscription_link, specifies required and optional parameters, and explains the status output. It distinguishes itself from sibling tools like cancel_subscription and query_payment_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It outlines when to use the tool (for checking a subscription) and when to use plan_id (disambiguation). It doesn't explicitly state when not to use it, but the sibling context makes it clear this is for status checking only.
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?
Adds valuable behavioral context beyond annotations: full refund by default, partial refund via amount parameter, and guardrail checks before gateway call. Annotations already indicate destructiveHint=true, but description enriches understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main purpose. No fluff, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, description covers prerequisites, behavioral traits, parameter usage, and guardrails. Sufficient for agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds meaning: clarifies amount as 'partial refund where supported', and ties tx_ref to query_payment_status usage. Adds value 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 'Refund a paid payment' with specific verb and resource. It also specifies the source (create_payment_link) and differentiates from siblings (create_payment_link, query_payment_status) by focusing on refund operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: only for payments created by create_payment_link, and mentions policy guardrails. Lacks explicit when-not-to-use or alternatives, but 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.
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!