Kenya Payments (Flutterwave — M-Pesa)
Server Details
Kenya payments for AI agents — M-Pesa via Flutterwave. Never holds funds.
- Status
- Unhealthy
- 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.5/5 across 6 of 6 tools scored.
Each tool has a clear and distinct purpose: creating payment links vs subscription links, querying their statuses separately, canceling subscriptions, and refunding payments. No overlaps.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., create_payment_link, query_subscription). No deviations.
6 tools is well-scoped for a focused payments/subscriptions service—enough to cover core operations without unnecessary bloat.
Covers the main CRUD-like operations: create and query for both payment and subscription, plus cancel and refund. Lacks update operations and listing, but these are minor for the domain.
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?
Describes the destructive action consistent with annotations. Adds important behavioral context about the subscription lifecycle (first payment required before cancellation is possible). 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 with no wasted words. Front-loaded with the action, then provides essential context.
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?
Fully adequate for a single-parameter tool with good annotations. Covers purpose, prerequisite, and parameter sourcing.
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 baseline is 3. The description adds value by explaining the parameter's source and timing, exceeding schema documentation.
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 the tool cancels a subscription to prevent renewal. Distinguishes from siblings like query_subscription and create_subscription_link by focusing on cancellation.
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 explains that the subscription_id is obtained from query_subscription and why it's not available at creation time. Provides clear when-to-use guidance.
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 KES for Kenya via Flutterwave. Buyer pays with M-Pesa (the rail Kenya actually uses), cards, bank transfer. 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_kes | Yes | Amount in KES (decimals allowed), e.g. 10. Minimum 1. | |
| 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?
Discloses beyond annotations: returns hosted checkout URL, payment completes automatically, no confirm step, credentials via header, and explains money flow (buyer→Flutterwave→merchant). Annotations already indicate openWorldHint=true and readOnlyHint=false, and the description adds concrete behavioral details.
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, well-structured paragraph. Front-loaded with core action, then details on payment methods, return value, credentials, and money flow. Every sentence adds value without 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?
Covers creation, payment methods, return URL, confirmation behavior, credentials, and money handling. Lacks mention of error handling or timeout behavior but is otherwise comprehensive for a payment link creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description does not add per-parameter details beyond the schema but provides context about payment process and credentials. Adequate but not exceptional.
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 creates a payment link in KES for Kenya via Flutterwave, specifies payment methods (M-Pesa, cards, bank transfer), and indicates it returns a checkout URL. This distinguishes it from the sibling tool 'query_payment_status' by context, though not explicitly.
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 implicit usage guidance: for Kenya payments, use this to generate a checkout link; payments are automatic without confirmation. No explicit 'when not to use' or direct comparison to the sibling, but the context is sufficient for typical use.
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 (KES, 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_kes | Yes | Amount charged per billing period (KES 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?
The description adds significant behavioral context beyond annotations: it explains the post-creation flow (buyer authorizes once, then auto-charges), the per-period amount meaning, and the owner policy guardrails. Annotations already indicate non-readonly and non-destructive, and the description aligns without 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?
The description is two sentences, front-loaded with the main purpose. Every sentence adds necessary information without 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?
The description covers the core behavior and parameter implications. However, it does not explicitly state the return value (the generated URL), which is a minor gap given no output schema. It also doesn't direct to cancel_subscription for cancellation, but the sibling list exists.
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 parameter descriptions. The description adds value by explaining that amount is per billing period and that customer_email is for receipts and renewal notices, which goes 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?
The description clearly states the tool creates a recurring subscription checkout link via Flutterwave, specifying the billing options and the payment flow. It differentiates from sibling tools like create_payment_link (one-time) by emphasizing 'recurring' and '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?
The description implies when to use (for recurring subscriptions vs one-time payments) by contrasting with create_payment_link. It also mentions guardrails and that the per-period amount is checked. However, it does not explicitly name alternatives or say when not to use.
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 Kenya 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?
The description discloses that the tool queries Flutterwave directly (external API), is pull-based, and defines 'paid=true when status is PAID'. This adds value beyond the readOnlyHint and openWorldHint annotations, providing clear behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: defining purpose, explaining the pull mechanism, and clarifying the result meaning. No unnecessary words, and the key information is front-loaded.
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 status check tool with one parameter and no output schema, the description covers purpose, behavior, and expected result. It lacks detail on the full response structure (e.g., other possible fields), but is generally 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?
The schema already fully documents the required tx_ref parameter with a clear description. The description does not add additional meaning or usage details for the parameter beyond what is in 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?
The description clearly states the tool checks whether a Kenya payment created by create_payment_link has been paid. The verb 'check' and resource 'payment status' are specific, and the mention of the sibling tool create_payment_link distinguishes it as a status query 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?
The description guides usage by stating 'pull-based, no webhook needed', implying it is used when polling is desired. However, it does not explicitly say when not to use it or compare to other status checking methods.
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?
Annotations already declare readOnlyHint=true. The description adds value by explaining the meaning of active=true and NOT_SUBSCRIBED_YET, and that the result includes subscription_id. 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?
The description is concise (4 sentences), well-structured, and front-loaded with purpose. Every sentence provides essential information without 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?
Given no output schema, the description explains key output fields (active status, subscription_id). It also mentions the status values. However, it does not list other possible fields, but it is fairly complete for a query tool.
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%, but the description adds significant context: it explains that customer_email is required, plan_id is optional and used for disambiguation, and that plan_id is returned at creation. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact purpose: 'Check a subscription created by create_subscription_link.' It specifies the verb ('check'), the resource ('subscription'), and the required parameter (customer_email). It distinguishes from siblings like cancel_subscription by mentioning that the result includes subscription_id for cancellation.
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 clear context: use this tool after creating a subscription link. It explains when to pass plan_id (to disambiguate multiple plans on same email). It does not explicitly state when not to use, but it is sufficiently clear.
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 the annotations (destructiveHint=true, readOnlyHint=false), the description adds that partial refunds are supported 'where supported' and that refunds respect owner policy guardrails, providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, no fluff, and front-loaded with the core purpose. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description covers the tool's purpose, parameters, partial vs full refund, and policy checks. It is fairly complete for a mutation tool, though it could mention the return value or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already clearly describes both parameters (tx_ref and amount) with adequate descriptions. The description's mention of 'pass amount for a partial refund' adds minimal extra value beyond what the schema provides.
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 a specific verb and resource. It also mentions the payment was created by create_payment_link, distinguishing it from sibling tools 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 clear guidance on when to use (refunding payments), and how to do full vs partial refunds. It also mentions policy guardrails, giving context for usage, though it doesn't explicitly state when not to use it.
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!