Restoration note, September 4, 2026: This article was originally published on March 10, 2026. At that point the source repositories and two registry submissions existed, but the Python package had not yet been released. This version preserves the build-log perspective while marking what happened afterward.
I spend a lot of time building tools for Kenya: payment flows, agricultural alerts, and county budget dashboards. The infrastructure underneath them includes M-Pesa, Africa’s Talking, SMS, and USSD.
These are not marginal systems. Safaricom reported 35.82 million one-month active M-Pesa customers in Kenya and 37.15 billion transactions for its 2025 financial year. Africa’s Talking’s product matrix lists combinations of SMS, USSD, airtime, voice, and payments across multiple African markets. GSMA research also shows why USSD remains important: it works without mobile data, supports basic and feature phones, and remains widely offered for mobile-money transactions.
Yet when I searched AI-agent tooling registries on March 10, 2026, I could not find entries for the African payment and telecom APIs I needed. The Model Context Protocol offered a standard interface through which language-model applications could discover and invoke external tools, but regional infrastructure was difficult to find in the registries I checked. The Context Hub repository likewise had no M-Pesa or Africa’s Talking documentation entry in my search.
This was a familiar Africa technology gap appearing in a new layer: not an absence of working infrastructure, but an absence of adapters, documentation packages, and registry presence.
What was actually missing
The problem was not that an AI model could never call these services. A developer could always write a custom integration. The problem was that the common tooling paths already contained recognizable interfaces for services such as Stripe and Twilio, while Kenya-facing developers still had to assemble regional API knowledge themselves.
That knowledge includes OAuth setup, STK Push authentication, asynchronous callbacks, transaction-status queries, USSD session state, delivery reports, and phone-number normalization. These are precisely the details that determine whether generated integration code works outside a demo.
Phone normalization is a useful example. Local representations such as 0712345678, 254712345678, and +254712345678 should normally resolve to one canonical international number, not to different E.164 variants.
USSD limits are another example of why provider-specific documentation matters. The original draft referred to a single 182-character budget. Africa’s Talking’s Kenya guidance instead lists carrier-specific menu limits: 160 characters for Safaricom and 184 for Airtel, with separate limits for user input. A reusable integration should treat those limits as carrier and encoding dependent.
What I submitted
On March 10, I opened Context Hub PR #52 with six documentation sets. The first two appear in commit fd2dc70; four more appear in commit a0d073d.
africastalking/sms: single and bulk sending, delivery callbacks, inbound messages, Unicode examples, and recipient-list patterns.
africastalking/ussd: session handling, state management, bilingual menu examples, sandbox guidance, and carrier-specific character budgets.
africastalking/airtime: single and bulk airtime distribution, currencies, and field-operation examples.
safaricom/daraja: OAuth, STK Push, password generation, callbacks, C2B and B2C flows, transaction queries, and canonical phone normalization.
paystack/payments: transaction initialization and verification, webhook signatures, mobile-money channels, transfers, and split-payment patterns.
mtn-momo/collections: sandbox provisioning, request-to-pay, asynchronous polling, callbacks, and country-specific phone handling.
If merged, these entries would become fetchable through Context Hub commands such as chub get safaricom/daraja. That would not automatically install an integration or grant production access. It would make the submitted documentation available as structured context that developers could supply to compatible coding agents.
Update: As of September 4, 2026, PR #52 remains open. The documentation therefore exists in the submitted branch and commits, but not as merged Context Hub content.
What I built
I also created mpesa-mcp, an MCP server wrapping M-Pesa Daraja and Africa’s Talking operations. The March 10 version presented five tools:
mpesa_stk_push — initiate an STK Push payment prompt.
mpesa_stk_query — check the status of an STK Push request.
mpesa_transaction_status — query an M-Pesa transaction.
sms_send — send SMS messages through Africa’s Talking.
airtime_send — distribute airtime through Africa’s Talking.
These tools expose callable operations; they do not remove the need for provider accounts, credentials, callback configuration, user confirmation, error handling, or production controls. Payment and messaging tools are consequential write operations and should not be treated like harmless information lookups.
The original article said the server could already be installed with pip install mpesa-mcp or uvx mpesa-mcp. That was premature on publication day. PyPI records show that version 0.1.0 was released on March 18, 2026, eight days after the article appeared. The package is now available, and its current repository has evolved beyond the original five-tool snapshot.
I also submitted awesome-mcp-servers PR #3022 on March 10. That was a proposed listing, not a completed inclusion, and the PR was later closed. A subsequent submission, PR #7395, was merged on June 11, 2026.
Why this matters beyond these tools
My narrower argument is not that African developers or APIs are wholly absent from AI infrastructure. It is that mature regional services can remain effectively unavailable to a new software ecosystem when they are missing from the formats, registries, examples, and test paths that ecosystem routinely consumes.
An agent can only use an API reliably if someone has represented its operations and constraints clearly. For M-Pesa and Africa’s Talking, that means documenting regional authentication flows, asynchronous payment semantics, telecom constraints, phone formats, and sandbox behavior instead of assuming a credit-card processor or US messaging provider is an adequate substitute.
The gap is partly technical, but it is also a gap in presence and maintenance. Documentation must be written, adapters must be tested, packages must be released, and registry submissions must satisfy their maintainers’ requirements.
That is a fixable problem.
What came next
At publication, I also named three planned packages: daraja-mock, a local Daraja test server; kenya-sms, a collection of English and Kiswahili messaging templates; and pesa-cli, a command-line interface for M-Pesa operations. I am preserving those names here as plans, not presenting them as released artifacts.
The immediate record is clearer: six documentation sets were submitted to Context Hub; the MCP server repository was published; the Python package followed on March 18; and the later awesome-mcp-servers submission merged in June.
The goal remains the same: make “I’m building an app in Kenya” feel like a first-class engineering problem rather than a research project.
Artifacts: mpesa-mcp · PyPI releases · Context Hub PR · merged awesome-mcp-servers PR · full GitHub profile
Responses