Tanzania Payments (Flutterwave — M-Pesa / Tigo Pesa)
Server Details
Tanzania payments for AI agents — M-Pesa / Tigo 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 targets a distinct operation: payment creation, status query, refund, subscription creation, cancellation, and query. No overlapping purposes; descriptions clearly differentiate them.
All tools follow a consistent verb_noun snake_case pattern (e.g., create_payment_link, query_payment_status, cancel_subscription). No mixing of conventions.
Six tools cover the essential payment and subscription lifecycle without excess. The number is well-scoped for the server's purpose.
Covers creation, status, refund, and subscription management. Minor gaps exist (e.g., no tool to list all payments or subscriptions) but core workflows are complete.
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 indicate destructiveHint=true, consistent with cancellation. Description adds context that subscription_id comes from query_subscription after payment, clarifying the required state before calling. 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, front-loaded with action. Every word adds value; no clutter.
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 single-parameter tool with annotations and no output schema, description fully enables correct invocation. Explains prerequisite and workflow.
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 100% with subscription_id described. Description explains origin and why not available at creation, adding significant 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?
Description states 'Cancel a subscription so it will not renew,' a specific verb-resource pair. It distinguishes from sibling tools like create_subscription_link (creation) and query_subscription (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?
Explicitly states when to use: requires subscription_id from query_subscription after first payment. It implies not to use before that, but does not state when not to use explicitly. References prerequisite tool.
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 TZS for Tanzania via Flutterwave. Buyer pays with M-Pesa Tanzania, Tigo Pesa, 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_tzs | Yes | Amount in TZS (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?
The description adds significant behavioral context beyond annotations: payment auto-completes, no confirm step, money flow (buyer->Flutterwave->merchant), credential requirements (header with test credentials), and that the service never touches funds. Annotations are sparse (readOnlyHint false, etc.), so the description fully compensates.
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 a single paragraph of ~80 words, front-loaded with the primary purpose. Every sentence contributes value, covering purpose, mechanics, credentials, and money flow 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 complexity of a payment tool (no output schema), the description is complete: it explains what it does, how it works, what it returns (checkout URL), authentication, test credentials, and transactional flow. No critical 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 has 100% coverage with descriptions for all 5 parameters (e.g., amount_tzs has min/max and unit). The description adds overall context (TZS, Flutterwave) but does not enhance parameter-level meaning beyond what the schema already provides. 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 payment link in TZS for Tanzania via Flutterwave, specifying payment methods and the return of a checkout URL. It distinguishes from sibling tools (query_payment_status, refund_payment) by focusing on creation.
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 for when to use the tool, including regional and provider details, and implicitly distinguishes from siblings. However, it lacks explicit when-not or alternative usage guidance, such as stating not to use for other regions or payment methods.
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 (TZS, 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_tzs | Yes | Amount charged per billing period (TZS 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 (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are consistent. The description adds behavioral context: the recurring charge mechanism, the policy guardrails, and that the amount is per billing period. This goes beyond the bare 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 two sentences, front-loads the core purpose, and every sentence provides necessary information without 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?
The description is complete enough for tool selection, given no output schema and moderate complexity. It covers purpose, behavior, and policy. It lacks details on the return value (the URL) and error cases, but these are not critical for selection.
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 descriptions for all 5 parameters. The description restates that 'Amount is per billing period' but does not add meaning beyond the schema. For a tool with full schema coverage, a baseline score 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?
The description clearly states the tool creates a recurring subscription checkout link via Flutterwave, specifying the resource (subscription link), verb (create), and billing options (TZS, monthly/yearly/weekly). This distinguishes it from sibling tools like create_payment_link (one-time) and cancel_subscription (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 explains the usage flow (buyer opens URL, authorizes once, auto-charged each period) and mentions policy guardrails (per-period amount checked). However, it does not explicitly state when not to use the tool or mention alternatives like create_payment_link for one-time payments.
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 Tanzania 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 adds valuable behavioral details beyond annotations: it's a direct query to Flutterwave, pull-based, and explains that paid=true when status is PAID. No contradictions with readOnlyHint or openWorldHint.
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: purpose, mechanism, result interpretation. No wasted words and front-loaded with key 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?
For a simple one-parameter query tool with good annotations, the description covers the essential behavioral aspects. It could add what happens if status is not PAID, but it's not necessary for agent selection.
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% and the description reinforces the parameter's relationship to create_payment_link but doesn't add new syntax or formatting 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 it checks payment status for Tanzania payments created by create_payment_link, differentiating it from sibling tools that create or refund 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?
It specifies this is pull-based and no webhook needed, indicating when to use it directly versus waiting for callbacks. It doesn't explicitly state when not to use, but the context is clear.
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 indicate readOnlyHint=true. Description adds value by explaining status values (ACTIVE, NOT_SUBSCRIBED_YET) and output behavior, including the subscription_id. No contradiction with readOnlyHint as it is a query.
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, front-loaded with purpose. Each sentence earns its place: purpose, required param, optional param with behavior, output details. 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?
Given no output schema, description adequately explains status values and prescribes an action (keep ID for cancel). For a simple 2-param tool with 100% schema coverage, this is 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 description adds minimal new meaning. The disambiguation hint for plan_id is present in both. 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?
The description clearly states the tool checks a subscription created by create_subscription_link, with specific verb 'Check' and resource 'subscription'. It distinguishes usage from siblings by focusing on querying 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?
Provides explicit guidance on required customer_email and optional plan_id for disambiguation. Mentions what to do with the result (keep subscription_id for cancel). Lacks explicit when-not-to-use, but context implies alternatives like cancel_subscription.
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?
Annotations indicate destructiveHint=true and idempotentHint=false. The description adds important behavioral context: refunds respect the x-agentpay-max-amount policy and check the amount before sending to the gateway. No contradiction 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 sentences, no wasted words. First sentence defines purpose and default behavior; second adds policy context. Front-loaded and 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?
Given the simple tool with only 2 parameters and no output schema, the description is complete. It explains refund types, policy, and parameter usage.
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 value: explains that 'amount' is optional for partial refunds, omission means full refund, and specifies currency unit. For 'tx_ref', it clarifies it's the same id used by query_payment_status.
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. It specifies that full refund is default, and a partial refund can be done by passing an amount. It also ties back to create_payment_link, distinguishing it from siblings.
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 implicitly tells when to use (after a payment is paid) and mentions policy guardrails. It does not explicitly state when not to use or alternatives, but since there is only one refund tool and it mentions 'paid payment', it's 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!