momo-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MOMO_API_KEY | No | The API key corresponding to MOMO_API_USER. Created by calling momo_provision_sandbox_user, or otherwise provided by MTN. | |
| MOMO_API_USER | No | The sandbox API user UUID. Created by calling momo_provision_sandbox_user, or otherwise provided by MTN. | |
| MOMO_CURRENCY | No | Currency for transactions. The sandbox settles only in EUR; setting another currency such as GHS against it is rejected. | |
| MOMO_MAX_AMOUNT | No | Maximum transaction amount in major units. Defaults to 1000. | 1000 |
| MOMO_ALLOW_PRODUCTION | No | Set to acknowledge production use. Required when MOMO_TARGET_ENVIRONMENT is a production country; without it the server refuses to start. | |
| MOMO_SUBSCRIPTION_KEY | Yes | Your MTN MoMo Collections subscription key, obtained from momodeveloper.mtn.com after subscribing to Collections. | |
| MOMO_TARGET_ENVIRONMENT | No | Target environment. Defaults to 'sandbox'. Setting a production country (e.g. 'mtnghana') selects production and also requires MOMO_ALLOW_PRODUCTION. | sandbox |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| momo_environmentA | Report which MTN MoMo environment this server targets, whether it moves real money, and the configured limits. Call this first, and always before any payment. |
| momo_provision_sandbox_userA | SANDBOX ONLY. Create an API user and API key in the MoMo sandbox and return them, so you can finish setup without hand-running three curl commands. The values must then be saved to MOMO_API_USER and MOMO_API_KEY. Refused outright in production, where MTN issues these credentials. |
| momo_verify_credentialsA | Check that the subscription key, API user and API key can mint an access token. Moves no money. |
| momo_account_balanceB | Read the balance of the configured MoMo account. Read-only. |
| momo_check_account_activeA | Check whether a phone number is a usable MoMo account before trying to charge it. Read-only and free. Worth calling before any request to pay. |
| momo_request_to_payA | Ask a subscriber to approve a payment on their phone. Returns a referenceId; the payment is PENDING until they approve, so poll momo_payment_status. In a production environment this collects REAL money and requires explicit confirmation from the human you are working for - never supply the confirmation phrase on your own initiative. |
| momo_payment_statusA | Look up a payment by the referenceId returned from momo_request_to_pay. Read-only. Status is PENDING, SUCCESSFUL or FAILED. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a clearly distinct action or resource: environment inspection, sandbox user provisioning, credential verification, balance reading, account activity checking, payment initiation, and payment status lookup. There is minimal risk of confusing tools, even though environment and verify_credentials both relate to configuration, because their outputs and purposes are explicitly different.
All tools share a consistent momo_ prefix and snake_case formatting. The action/resource phrasing is slightly mixed (e.g., momo_environment and momo_account_balance are noun-like, while momo_verify_credentials and momo_request_to_pay are verb-like), but the pattern remains readable and predictable.
Seven tools is well-scoped for a focused MoMo payments integration surface. Each tool earns its place by covering setup, verification, account validation, payment initiation, and status checking without obvious redundancy.
The surface covers the core collection workflow end to end: environment discovery, credential setup and verification, account validation, payment request, and status polling. Minor gaps exist around refunds, disbursements, or transaction listing, but those may be outside the intended collections-only scope.