What can you do with this server?

This server enables AI agents to interact with East African fintech APIs — M-Pesa (Safaricom Daraja) and Africa's Talking — for payments, SMS, and airtime operations. * mpesa_stk_push: Trigger an M-Pesa STK Push payment prompt to a customer's phone; the customer enters their PIN to complete payment. Returns a CheckoutRequestID for tracking. * mpesa_stk_query: Check the status of a previous STK Push request (ResultCode 0 = success, 1032 = cancelled, 1037 = timed out). * mpesa_transaction_status: Query any M-Pesa transaction by receipt number (e.g., QKL8XXXXXX), useful for payment verification and reconciliation. * sms_send: Send SMS to 1–1,000 recipients across 20+ African countries via Africa's Talking. Supports Unicode text including Kiswahili. * airtime_send: Send airtime top-ups to subscribers on MTN, Safaricom, Airtel, or Vodafone networks in multiple currencies (KES, NGN, GHS, UGX, TZS, RWF, ZAR).

Which integrations are available for this server?

Enables sending airtime top-ups to Airtel subscribers across multiple African countries via the Africa's Talking API.

de en es ja ko ru zh

mpesa-mcp

by gabrielmahia

Overview Schema Source Related Servers Discussions Admin

Python

Remote

mpesa-mcp

MCP server for East African fintech APIs — M-Pesa (Safaricom Daraja) and Africa's Talking

Give your AI agent the ability to trigger M-Pesa payments, check transaction status, send SMS, and top up airtime across 20+ African telecom networks.

Tests PyPI License: MIT Glama Score Glama NSA MCP Compliant

mpesa-mcp MCP server

Tested With

claude-sonnet-5  (recommended — call get_model_hint() for guidance)
claude-opus-4-8  (for highest-accuracy compliance reasoning)

Claude Sonnet 5 (released June 30, 2026) finishes multi-step M-PESA workflows without stopping short and self-corrects tool-call errors without prompting. Terminal-Bench score 80.4% vs Sonnet 4.6's 67.0% — the benchmark most analogous to payment agent work.

Related MCP server: M-Pesa MCP Server

Why this exists

M-Pesa processes more transactions per day than PayPal does in Africa. Africa's Talking reaches users in 20+ countries on basic phones via SMS and USSD. Neither has an MCP server.

This means every AI agent built today — Claude, GPT, Gemini, or any MCP-compatible runtime — cannot trigger an M-Pesa payment or send a Kiswahili SMS without custom integration work.

mpesa-mcp closes that gap in one pip install.

Tools

Tool	Description
`mpesa_stk_push`	Trigger STK Push payment prompt on customer's M-Pesa phone
`mpesa_stk_query`	Check status of an STK Push request
`mpesa_transaction_status`	Query any M-Pesa transaction by receipt number
`sms_send`	Send SMS to 1–1,000 recipients across African networks
`airtime_send`	Send airtime top-up to any subscriber (KES, NGN, GHS, UGX, etc.)

Coverage

M-Pesa: Kenya (Safaricom Daraja v3) — STK Push, C2B, transaction status
SMS/Airtime: Kenya, Nigeria, Ghana, Tanzania, Uganda, Rwanda, South Africa, and 15+ more via Africa's Talking

Glama (hosted MCP)

mpesa-mcp is available as a hosted MCP server on Glama:

mpesa-mcp MCP server mpesa-mcp score

Security — NSA MCP Guidance Compliant

mpesa-mcp was updated in response to NSA CSI U/OO/6030316-26 (May 2026) — the NSA Artificial Intelligence Security Center's Cybersecurity Information Sheet on Model Context Protocol security.

The implementation below documents compliance against the NSA's MCP security framework, control by control.

NSA Control	Implementation
Parameter validation	KE phone regex `^254[17]\d{8}$` + amount bounds [1–150,000 KES]
Audit logging	Structured log per tool call; phone numbers SHA-256 hashed
Token lifecycle	OAuth token cached with expiry; auto-refreshed
Error containment	Structured error dicts; no raw exception propagation
HTTPS enforcement	All Daraja API calls HTTPS-only
No hardcoded secrets	All credentials via environment variables

See SECURITY.md for the full compliance table.

Reference: NSA CSI_MCP_SECURITY.pdf — May 2026, UNCLASSIFIED

Install

pip install mpesa-mcp

Or run directly with uvx:

uvx mpesa-mcp

Configuration

Set these environment variables before starting the server:

# M-Pesa (Safaricom Daraja)
MPESA_CONSUMER_KEY=your_consumer_key
MPESA_CONSUMER_SECRET=your_consumer_secret
MPESA_SHORTCODE=174379               # sandbox test shortcode
MPESA_PASSKEY=your_passkey
MPESA_CALLBACK_URL=https://yourdomain.com/mpesa/callback
MPESA_SANDBOX=true                   # set false for production

# Africa's Talking
AT_USERNAME=sandbox                  # your AT username (sandbox for testing)
AT_API_KEY=your_at_api_key

Sandbox credentials

M-Pesa sandbox: https://developer.safaricom.co.ke — create a free app to get test credentials.

Test shortcode: 174379
Test passkey: bfb279f9aa9bdbcf158e97dd71a467cd2e0c893059b10f78e6b72ada1ed2c919

Africa's Talking sandbox: https://account.africastalking.com — use username=sandbox, any API key.

Usage with Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "mpesa": {
      "command": "uvx",
      "args": ["mpesa-mcp"],
      "env": {
        "MPESA_CONSUMER_KEY": "your_key",
        "MPESA_CONSUMER_SECRET": "your_secret",
        "MPESA_SHORTCODE": "174379",
        "MPESA_PASSKEY": "your_passkey",
        "MPESA_CALLBACK_URL": "https://yourdomain.com/mpesa/callback",
        "MPESA_SANDBOX": "true",
        "AT_USERNAME": "sandbox",
        "AT_API_KEY": "your_at_key"
      }
    }
  }
}

Usage with Claude Code

claude mcp add mpesa -- uvx mpesa-mcp

Set env vars in your shell before running claude.

Example prompts

Once connected, you can ask your AI agent:

"Send KES 500 STK Push to +254712345678 for order #1234"

"Check if the payment QKL8ABC123 has been received"

"Send an SMS to these 50 farmers with today's maize price: [list]"

"Top up KES 50 airtime for our field agents: [list of numbers]"

Real-world scenarios

Field agent payment dispatch

"Send KES 300 STK Push to each of these 12 field agents for today's data collection: [list]"

The agent triggers 12 sequential STK pushes, tracks each checkout_request_id, and polls for confirmation — without any code from you.

Farmer alert + airtime

"SMS these 200 Garissa farmers that the river is rising. Then top up KES 20 airtime each so they can call in reports."

One prompt → 200 SMS messages and 200 airtime top-ups across Safaricom, Airtel, and Telkom.

Payment reconciliation

"Check whether receipt OKL8M3B2HF was a successful payment and how much it was for"

Useful for support agents using Claude to verify M-Pesa transactions in real time.

Tool annotations

All tools declare MCP tool annotations so clients can gate calls appropriately:

Tool	readOnly	destructive	idempotent
`mpesa_stk_push`	❌	✅	❌
`mpesa_stk_query`	✅	❌	✅
`mpesa_transaction_status`	✅	❌	✅
`sms_send`	❌	✅	❌
`airtime_send`	❌	✅	❌

Claude Desktop and other MCP clients will request confirmation before triggering payment, SMS, or airtime operations.

Server discovery

Capabilities are advertised via .well-known/mcp.json — the emerging MCP Server Cards standard. Registries and browsers can index this server's tools without connecting to it.

# Check capabilities
curl https://raw.githubusercontent.com/gabrielmahia/mpesa-mcp/main/.well-known/mcp.json

Testing and accuracy

The MCP ecosystem benchmark (CData, 2026) found most MCP servers accurate 60–75% of the time on complex queries — particularly silent failures on write operations and partial parameter application.

mpesa-mcp is tested against all three Kenyan phone number formats, boundary amount values, and missing optional fields:

pytest tests/ -v  # run full suite
pytest tests/test_phone_formats.py  # format normalization
pytest tests/test_boundary_amounts.py  # min/max amount edge cases

Write operations (STK push, SMS, airtime) have explicit validation before any API call is made.

Ecosystem context — Mojaloop + MCP

Mojaloop (funded by the Gates Foundation) handles payment interoperability — connecting banks, mobile money wallets, and merchants across DFSPs in East Africa and beyond.

mpesa-mcp handles the AI agent tooling layer — enabling AI coding assistants to trigger and query M-Pesa payments programmatically.

These are complementary:

Mojaloop: the interoperability rails between financial providers
mpesa-mcp: the MCP interface layer that connects AI agents to those rails

See the Mojaloop documentation contribution for more on this pattern.

MCP vs A2A — two different protocols

mpesa-mcp implements MCP (Model Context Protocol) — how an AI agent talks to tools.

There is a complementary protocol, A2A (Agent-to-Agent), which handles how agents talk to each other. They solve different problems and work together:

MCP: Your AI agent → mpesa-mcp → Daraja API / Africa's Talking
A2A: Orchestrator agent ↔ payment sub-agent ↔ notification sub-agent

For most integrations you only need MCP. A2A becomes relevant when you're building multi-agent systems where a payment workflow coordinates with other specialized agents.

Development

git clone https://github.com/gabrielmahia/mpesa-mcp
cd mpesa-mcp
pip install -e ".[dev]"
pytest tests/ -v

Security

Do not commit API keys. Use environment variables or a secrets manager.
Report vulnerabilities to: contact@aikungfu.dev

Research Context

MCP ecosystem benchmark (CData, 2026): Most MCP servers achieve 60-75% accuracy on complex queries. mpesa-mcp includes explicit validation and bounds checking to exceed this baseline.

Swahili AI accuracy (arXiv:2509.04516, 2025): AI models produce 4× more errors in Swahili than English. mpesa-mcp's Swahili-native tool descriptions are designed to minimize this gap for Swahili-speaking users by eliminating the translation step in tool selection.

MCP security research (arXiv:2603.18063, arXiv:2603.21642, 2026): Prompt injection via tool descriptions is the primary MCP attack vector. mpesa-mcp mitigates this through static, versioned tool descriptions and strict input validation.

Related infrastructure:

wapimaji-mcp — Kenya water/drought MCP
civic-agent-kit — Kenya civic data MCP
swahili-health-mcp — Kenya DHIS2 health data MCP
kenya-legal-rag — Kenya legal corpus MCP
Full portfolio: gabrielmahia.github.io

License

Stay updated

Get notified of new releases and East African API developments: Subscribe to updates →

Or watch this repo on GitHub for release notifications.

Sibling packages

Package	Install	Description
wapimaji-mcp	`pip install wapimaji-mcp`	Kenya drought intelligence MCP server
civic-agent-kit	`pip install civic-agent-kit`	East African civic AI SDK

All MIT · All part of the East African civic AI stack

Package	Install	Description
wapimaji-mcp	`pip install wapimaji-mcp`	Kenya drought intelligence MCP server
kenya-health-mcp	`pip install kenya-health-mcp`	Kenya health data MCP — NHIF, facilities, maternal, rights
civic-agent-kit	`pip install civic-agent-kit`	East African civic AI SDK

Full portfolio: gabrielmahia.github.io

Part of the East Africa Coordination Stack

This MCP server is one of 32 tools in the Kenya coordination infrastructure. Connect it to africa-coord-bus — the coordination event bus that routes signals between domains automatically.

pip install africa-coord-bus

All 32 servers: pypi.org/user/gmahia Live demo: coord-cascade-demo

IP & Collaboration

MIT licensed. Feedback via GitHub Issues only — pull requests are not accepted. Demo data is labeled DEMO and is not suitable for operational decisions. Full policy: docs/architecture/IP_POLICY.md. Security reports: see SECURITY.md.

Part of the East Africa coordination stack

Install & run: pip install reli-cli && reli list — 33 MCP servers on the official MCP Registry under io.github.gabrielmahia
Evaluate any model on Swahili agent tasks: kipimo · dataset · leaderboard
Coordinate across servers: africa-coord-bus — offline-first event bus with a built-in Kenya routing table
Datasets: huggingface.co/gmahia · Docs hub: nairobi-stack

Model-agnostic by design: closed APIs, open-weight models, and small distilled models are all first-class citizens.

Available Tools

5 tools

airtime_sendSend AirtimeA

Destructive

Send airtime top-up to any MTN/Safaricom/Airtel/Vodafone subscriber. Common use: NGO field incentives, survey rewards, agent payouts. No real airtime sent in sandbox mode.

ParametersJSON Schema

Name	Required	Description	Default
`phone`	Yes	Recipient phone in E.164 format e.g. '+254712345678'
`amount`	Yes	Amount as string e.g. '50' (KES 50). Minimum KES 10 in production.
`currency_code`	No	ISO currency code: KES, NGN, GHS, UGX, TZS, RWF, ZAR	KES

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructive/destructiveHint=true. Description adds valuable sandbox behavior disclosure. Does not discuss other aspects like auth or rate limits, but the added sandbox note is useful 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each adding distinct value: action, use cases, sandbox note. No fluff, highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (return values not needed), the description covers purpose, common usage, and sandbox behavior. Lacks prerequisites or error scenarios, but sufficient for a simple tool with good annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already describes each parameter in detail (including minimum amount in production). Description does not add new parameter information beyond what's in the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states action (send airtime top-up) and target (specific network subscribers). Common use cases provided. Distinguishes from siblings like mpesa_stk_push which are for money transfers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Lists common use cases (NGO incentives, survey rewards, agent payouts) and mentions sandbox mode behavior. Does not explicitly compare to alternatives, but given sibling tools, context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mpesa_stk_pushM-Pesa STK PushA

Destructive

Trigger an M-Pesa STK Push — sends a payment prompt to the customer's phone. The customer enters their M-Pesa PIN to complete payment. Returns a CheckoutRequestID to track the transaction with mpesa_stk_query. Async: use mpesa_stk_query after 10-30 seconds to check completion.

ParametersJSON Schema

Name	Required	Description	Default
`phone`	Yes	Customer phone number (any Kenyan format: +254..., 07..., 254...)
`amount`	Yes	Amount in KES (whole number, minimum 1)
`account_ref`	Yes	Account reference shown to customer on their phone (max 12 chars)
`description`	No	Transaction description (max 13 chars)	Payment

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond annotations: it explains that the tool is async, that the customer enters their PIN to complete payment, and that a CheckoutRequestID is returned for follow-up. This aligns with destructiveHint=true and provides useful actionable information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four short sentences, all of which provide necessary information. It front-loads the primary action and sequentially covers process, return value, and follow-up. There is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential aspects of a payment initiation tool: what it does (trigger STK push), the user interaction (customer enters PIN), the result (CheckoutRequestID), and the asynchronous follow-up (use mpesa_stk_query after 10-30 seconds). With an output schema present, the description does not need to detail return fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all parameters. The tool description does not add additional meaning beyond the schema (e.g., no examples or format clarification). Baseline 3 applies as schema already documents parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool triggers an M-Pesa STK Push, sends a payment prompt to the customer's phone, and returns a CheckoutRequestID for tracking. It distinguishes itself from sibling tools like mpesa_stk_query by noting that the query tool is for checking completion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the sibling tool mpesa_stk_query (after 10-30 seconds) to check completion. It implies that this tool is for initiating payments, but does not explicitly state when not to use it or mention alternatives like airtime_send.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mpesa_stk_queryM-Pesa STK QueryA

Read-onlyIdempotent

Check the status of an STK Push request. Poll this 10-30 seconds after calling mpesa_stk_push. ResultCode 0 = success, 1032 = cancelled by user, 1037 = timed out.

ParametersJSON Schema

Name	Required	Description	Default
`checkout_request_id`	Yes	CheckoutRequestID from mpesa_stk_push response

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, idempotentHint), the description adds polling timing and result code meanings, disclosing behavioral traits like non-immediate result and cancellation handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, each essential: purpose, timing advice, and result interpretation. No extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and existing output schema, the description fully covers polling strategy, result codes, and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description merely restates the parameter's purpose ('CheckoutRequestID from mpesa_stk_push response') without adding additional meaning or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Check the status of an STK Push request' with a specific verb and resource, distinguishing it from siblings like mpesa_stk_push (initiates) and mpesa_transaction_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to poll 10-30 seconds after calling mpesa_stk_push, and interprets result codes (0=success, 1032=cancelled, 1037=timed out), providing clear when-to-use and expected outcomes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mpesa_transaction_statusM-Pesa Transaction StatusA

Read-onlyIdempotent

Query the status of any M-Pesa transaction by receipt number. Requires MPESA_INITIATOR_NAME and MPESA_SECURITY_CREDENTIAL env vars.

ParametersJSON Schema

Name	Required	Description	Default
`transaction_id`	Yes	M-Pesa receipt number e.g. QKL8XXXXXX

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive. Description adds valuable prerequisite info (env vars) beyond annotations. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both essential. Front-loaded with purpose, then prerequisite. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple tool with output schema and rich annotations, description is mostly complete. Missing rate limits or side-effect details, but not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameter with example. Description adds no new semantics, so baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear specific verb (Query) and resource (transaction status) with receipt number. Distinguishes from sibling tools like airtime_send and sms_send.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions required environment variables but does not explicitly state when to use this tool vs alternatives like mpesa_stk_query. Usage is implied by name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sms_sendSend SMSA

Destructive

Send SMS to one or many recipients via Africa's Talking. Supports up to 1,000 recipients per call. Works across Kenya, Nigeria, Ghana, Tanzania, Uganda, and 15+ African markets. Returns per-recipient status and cost.

ParametersJSON Schema

Name	Required	Description
`message`	Yes	SMS message text. Unicode supported (Kiswahili, etc.)
`sender_id`	No	Optional pre-registered alphanumeric sender ID
`recipients`	Yes	List of phone numbers in E.164 format e.g. ['+254712345678']

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and idempotentHint=false. The description adds valuable behavioral details: the maximum recipient limit, geographic coverage, and that it returns per-recipient status and cost. No contradictions 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, each serving a distinct purpose: what the tool does, its capacity and scope, and its return value. No wasted words, and the most critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three well-documented parameters and an existing output schema, the description covers the essential aspects: operation, capacity, geographic scope, and return format. It is sufficiently complete for an agent to understand and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema itself clearly documents all three parameters. The description adds no additional parameter-level meaning beyond what is in the schema (e.g., it mentions Unicode support which is already in the message description). Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends SMS via Africa's Talking, specifies the maximum recipients (1,000), mentions geographic coverage, and indicates return of per-recipient status and cost, distinguishing it from sibling tools like airtime_send or mpesa_stk_push which perform different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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 (sending SMS to one or many recipients) and includes practical limits (1,000 recipients). It does not explicitly mention when not to use it or compare to alternatives, but the sibling tools are sufficiently different that no confusion arises.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Apr 27, 2026
- First observedairtime_send
- First observedmpesa_stk_push
- First observedmpesa_stk_query
- First observedmpesa_transaction_status
- First observedsms_send

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-04 05:45 across 5 tools

Disambiguation5/5

Each tool targets a distinct function: airtime sending, STK push initiation, STK push status query, transaction status by receipt, and SMS sending. There is no overlap or ambiguity.

Naming Consistency4/5

Most tools follow a verb_noun or noun_verb pattern (e.g., airtime_send, sms_send, mpesa_stk_push), but mpesa_transaction_status lacks a verb, breaking the pattern slightly.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose, covering core M-Pesa and SMS operations without being too few or too many.

Completeness3/5

The set covers STK push initiation/query and basic transaction status, but lacks airtime status, B2C/C2B transfers, or account balance queries, leaving notable gaps for a full M-Pesa integration.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

SIMcloud
za.co.simcloud
South African MCP server for airtime, data, SMS, VAS, electricity, balance, and network lookup.
Communication Finance Energy
2
inflowOAuth
ai.inflowpay.app
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
Agent Orchestration Autonomous Agents Payments & Billing
26
modern-treasury A
io.usefulapi
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Finance Payments & Billing
172
codat A
io.usefulapi
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Finance ERP Systems Data Platforms
282

Related MCP Servers

PayLink MCP Serverofficial
Finance Payments & Billing
paylink-ai
F
license
Not graded
quality
D
maintenance
Open-source MCP server that streamlines payment integration for AI agents and financial apps in Africa, providing unified tools for providers like M-Pesa.
Updated a year ago (2025-07-30 14:30 UTC)
1
-
M-Pesa MCP Server
Payments & Billing Finance Autonomous Agents
breezykalama
F
license
Not graded
quality
C
maintenance
An experimental MCP server that lets AI agents interact with guarded payment workflows through typed tools, enabling safe agent-assisted payments with M-Pesa and mock Airtel Money.
Updated 3 months ago (2026-06-05 11:12 UTC)
2
-
Safaricom Daraja MCP Server
Finance Payments & Billing
mboya
F
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that integrates Safaricom's M-PESA Daraja API with Claude, enabling natural language payment processing and real-time transaction notifications.
Updated 4 months ago (2026-05-26 15:47 UTC)
3
-
Interswitch MCP Server
Finance Payments & Billing
Dairus01
A
license
C
quality
D
maintenance
An MCP server that enables AI assistants to interact with Interswitch APIs for payments, transfers, VAS, cardless paycodes, Transaction Search, Card 360, lending, payouts, agency banking, and fintech card-processing utilities.
Updated 4 months ago (2026-05-07 01:36 UTC)
74
58 npm
1
MIT

mpesa-mcp

Tested With

Why this exists

Tools

Coverage

Glama (hosted MCP)

Security — NSA MCP Guidance Compliant

Install

Configuration

Sandbox credentials

Usage with Claude Desktop

Usage with Claude Code

Example prompts

Real-world scenarios

Tool annotations

Server discovery

Testing and accuracy

Ecosystem context — Mojaloop + MCP

MCP vs A2A — two different protocols

Development

Security

Research Context

License

Stay updated

Sibling packages

Related packages

Part of the East Africa Coordination Stack

IP & Collaboration

Part of the East Africa coordination stack

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

PayLink MCP Serverofficial