DEV Community: Gabriel Mahia

3,000 Patients Per Worker: Can AI Support Kenya's Community Health Workers?

Gabriel Mahia — Sun, 19 Jul 2026 10:00:00 +0000

Kenya has approximately 100,000 Community Health Workers (CHWs — locally called Community Health Extension Workers, or CHEWs). They cover a population of 54 million. That's roughly one CHW per 540 people, but in rural areas the ratio reaches 3,000:1.

These workers are the first and often only medical contact for millions of Kenyans. They do triage. They decide who needs a hospital referral. They counsel on pregnancy, malnutrition, fever, diarrhoea. They work from memory and a printed protocol card.

afyanipoa (afya nzuri = good health in Swahili, "poa" = cool) is an AI clinical co-pilot for these workers.

The Research Basis

arXiv:2408.17216 — "Democratizing AI in Africa: Federated Learning for Low-Resource Edge Devices" (2024)

This paper demonstrated that federated learning can be deployed on Raspberry Pi-class devices (the computing tier of affordable Android phones) in 5 African countries simultaneously, achieving acceptable model accuracy without centralized data collection. The implication: clinical AI doesn't require cloud connectivity.

WHO Community Health Workers Reference Group (2022): The WHO documents that CHW programs are most effective when workers have access to real-time decision support — but most programs only provide printed job aids updated annually.

Kenya MOH CHEW Curriculum: The Kenya Ministry of Health publishes the official training curriculum for CHEWs. The integrated management protocols for fever, cough, diarrhoea, ANC, and malnutrition are well-defined and systematizable.

What afyanipoa Does

The app has three layers:

1. Protocol library (always available, no AI needed)

Embedded Kenya MOH protocols for 8 conditions: fever, cough, diarrhoea, malnutrition, ANC, family planning, mental health, TB screening. Danger signs, referral triggers, dosing by age/weight. Zero API calls required.

2. AI clinical guidance (when API key is configured)

A CHW describes a patient's complaint in Swahili. The AI synthesizes the relevant protocol sections with the specific presentation and returns:

ISHARA ZA HATARI / DANGER SIGNS (check first)
TATHMINI / ASSESSMENT (what to examine)
MATIBABU / IMMEDIATE ACTION
PELEKA / REFERRAL (when, where, why)
FUATILIA / FOLLOW-UP

3. Emergency contacts (always visible)

0800 720 571 (Kenya health emergency line), county referral hospital numbers, maternal emergency contacts.

The Safety Architecture

This is safety-critical software. The design decisions reflect that:

DEMO label: visible on every screen
AI output: labeled "decision support, not diagnosis"
Danger signs: displayed FIRST, before any AI output
Referral bias: when in doubt, the prompt leans toward referral
Emergency contacts: persistent, not hidden in menus

The Gemini prompt explicitly instructs the model:

"When in doubt between management at home and referral, recommend referral. A missed referral in the field has worse consequences than an unnecessary one. This is decision SUPPORT — the CHW makes the final call."

The Endpoint Fix

One lesson from this deployment: always use the stable /v1/ endpoint, not /v1beta/.

# Wrong — returns 404 for gemini-2.0-flash
url = f"generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent"

# Right — try v1 first, fall back to v1beta
for ver in ("v1", "v1beta"):
    url = f"generativelanguage.googleapis.com/{ver}/models/gemini-2.0-flash:generateContent"
    try:
        # ... call ...
        return result
    except HTTPError as e:
        if ver == "v1beta": raise
        continue

This pattern has since been applied to all Gemini-enabled apps in this portfolio.

Deploy It Today

# Streamlit Cloud — free tier
# Repo: github.com/gabrielmahia/afyanipoa
# Secret: GOOGLE_API_KEY = "your-gemini-key"

Get a free Gemini API key at console.cloud.google.com → Gemini API → Enable → Create key.

github.com/gabrielmahia/afyanipoa · CC BY-NC-ND 4.0

Reputation Portability: The Missing Infrastructure for Economic Mobility

Gabriel Mahia — Thu, 16 Jul 2026 10:00:00 +0000

A skilled plumber in Chicago can move to Los Angeles and immediately find work. Her Yelp reviews, contractor license, and Angie's List history travel with her. Strangers trust her before she's done a single job.

A skilled mason in Mombasa cannot take her reputation to Nairobi. Trust is tribal and local. Hiring defaults to personal networks. The most talented people outside existing networks are invisible.

This is not a cultural problem. It's an infrastructure problem.

What Reputation Portability Infrastructure Looks Like

In mature economies, the infrastructure exists in fragments:

Uber/Lyft: Star ratings that follow a driver across cities
LinkedIn: Endorsements and work history that cross borders
BBB (Better Business Bureau): Verified complaint and resolution history
Angie's List / Thumbtack: Job completion ratings for home services
Upwork JSS: Job Success Score based on completed contracts
Professional licensing boards: Verifiable credentials (doctor, electrician, contractor)

Each of these solves the same problem: how do you compress trust between strangers at scale?

sifa-mcp (Sifa = reputation/praise in Swahili) is a portable reputation MCP server that implements this infrastructure for East Africa's informal economy.

The Trust Score Architecture

from sifa_mcp import create_worker_profile, add_service_record, get_reputation_profile

# Create a portable profile
profile = create_worker_profile(
    full_name="Amina Odhiambo",
    phone="0712345678",
    primary_skill="construction",
    sub_skills="masonry,tiling,plastering",
    location="Mombasa",
    years_experience=8
)
# → profile_id: "SFA-A3F2B19C4E1D"

# Add a completed job
add_service_record(
    profile_id="SFA-A3F2B19C4E1D",
    client_name="ABC Contractors",
    client_phone="0722000000",
    service_type="Kitchen tiling",
    duration_days=5,
    payment_kes=15000,
    client_rating=5
)

# Check trust for a new employer
profile_data = get_reputation_profile(
    profile_id="SFA-A3F2B19C4E1D",
    requester_context="employer"
)
# → trust_tier: "ESTABLISHED"
# → recommendation: "Good track record. Suitable for most engagements."

The Score Decomposition

The trust score (0–100) is built from four signals:

Signal	Max Points	Rationale
Job volume	30	Demonstrates activity, not just registration
Average quality	35	Client-rated — heaviest weight
Verified records	20	Client OTP confirmation prevents fabrication
Tenure	15	Long history = stability signal

This maps directly to how humans assess trust: frequency + quality + verification + history.

The Production Path

sifa-mcp is DEMO infrastructure. The in-memory profile store needs to be backed by a persistent database. More critically, production requires identity verification tied to Kenya's Huduma Number / NIIMS system — to prevent workers from fabricating verified records.

The regulatory and identity infrastructure for this exists in Kenya. The coordination layer (portable reputation MCP) does not. That's the gap sifa-mcp fills — and the conversation it starts.

Why NITA Alignment Matters

The skill categories in sifa-mcp are aligned with Kenya's National Industrial Training Authority trade classifications. This isn't accidental — NITA certification is the existing institutional trust anchor for skilled tradespeople. A sifa-mcp score that references NITA-certified training becomes part of a verifiable credential chain.

pip install sifa-mcp

github.com/gabrielmahia/sifa-mcp · MIT License

Parametric Insurance: When Satellite Data Replaces the Claims Adjuster

Gabriel Mahia — Mon, 13 Jul 2026 10:00:00 +0000

Traditional crop insurance requires a claims adjuster to visit a farm, document damage, and approve a payout. In Kenya, where farms average 1.5 hectares and are scattered across 47 counties, this is economically impossible to do at scale.

The result: 2.3% insurance penetration. One bad drought = financial ruin.

Parametric insurance solves this by replacing the claims adjuster with satellite data.

How Parametric Insurance Works

Instead of insuring against "crop loss" (which requires verification), parametric insurance insures against a trigger event — a measurable proxy for loss:

Rainfall below 60mm in a 30-day growing period → automatic payout
NDVI (normalized difference vegetation index) below 0.3 in July → payout
Temperature above 38°C for 5+ consecutive days → payout

No claims process. No adjuster. If the satellite says the trigger fired, the payout happens automatically — within 72 hours, direct to M-PESA.

The Research Basis

ACRE Africa (2023): ACRE (Agriculture and Climate Risk Enterprise) has facilitated over $200M in parametric insurance across 12 African countries. Their methodology uses NDMA (National Drought Management Authority) data as the primary trigger source for Kenya.

NDMA Kenya: The NDMA publishes monthly county drought monitoring reports with rainfall deficit data, NDVI scores, and livestock condition indices. This is the data layer that makes parametric insurance possible.

IRI (International Research Institute for Climate and Society): El Niño/La Niña forecasting with 3-month lead time has been validated as a viable basis for planting-season insurance triggers in East Africa.

bima-mcp Implementation

from bima_mcp import parametric_risk_score

result = parametric_risk_score(
    county="Nakuru",
    crop="maize",
    season="long_rains",
    coverage_kes=50000
)
# → risk_tier: "MEDIUM",
# → trigger_threshold: "rainfall < 65mm in March-May growing period",
# → recommended_premium_kes: 3750,
# → payout_probability: 0.28,
# → data_source: "DEMO — modeled on NDMA county reports"

The Community Pool Tool

One of the more interesting tools is community_pool_calculator, which models informal risk-sharing:

from bima_mcp import community_pool_calculator

result = community_pool_calculator(
    group_size=25,
    avg_farm_value_kes=120000,
    target_coverage_pct=0.6,
    drought_probability=0.25
)
# → pool_size_needed_kes: 450000,
# → monthly_contribution_kes: 1500,
# → confidence_interval: "90% probability of full coverage for any single member in any given year"

Chama groups (informal savings societies) are already the primary financial institution for millions of Kenyan women. Parametric pooling maps directly to existing behavior.

What bima-mcp Covers

6 tools:

nhif_coverage_query — NHIF benefit lookup by category
parametric_risk_score — NDMA-based crop risk scoring
microinsurance_comparison — product comparison across providers
community_pool_calculator — informal risk-sharing models
claim_eligibility — trigger-based eligibility check
insurance_gap_analysis — what's uninsured in a given county

pip install bima-mcp

github.com/gabrielmahia/bima-mcp · MIT License

The Information Asymmetry That Costs East African Farmers Billions

Gabriel Mahia — Fri, 10 Jul 2026 10:00:00 +0000

A trader drives from Nairobi to Nakuru on Monday morning. Before leaving, he checks wholesale prices at Wakulima Market. He knows maize is 12% higher in Nairobi this week than last.

The farmer he buys from doesn't know this.

That information gap is not accidental. It's structural, persistent, and extractable by anyone with market access. The World Bank estimated in 2016 that price information asymmetries account for 10–15% of post-harvest losses in Sub-Saharan Africa. For Kenya's 8M+ smallholder farmers, that's billions in foregone income annually.

soko-mcp is a commodity price intelligence MCP server that begins to close this gap.

The Research Basis

Suri & Jack (2016): M-PESA adoption in Kenya lifted 194,000 households out of poverty, disproportionately women — primarily through improved market access and ability to store value. The mechanism: reduced friction in market participation.

World Bank "ICT and Agricultural Markets" (2016): In markets where farmers received SMS price updates, they achieved 8–10% higher farm-gate prices by timing sales or traveling to better markets.

EAGC East Africa Regional Market Monitor: The East Africa Grain Council publishes weekly price data for 12 commodities across 8 countries. This data exists. It's just not integrated into tools farmers actually use.

The Sell/Hold Problem

The core decision a farmer faces post-harvest:

"Should I sell my 50 bags of maize now, or store them for 2 months?"

This requires three inputs:

Current market price vs. historical average
Expected price trajectory (seasonal pattern)
Cost of storage (per bag per month)

from soko_mcp import sell_hold_decision

result = sell_hold_decision(
    commodity="maize",
    market="nakuru",
    quantity_bags=50,
    storage_cost_per_month_kes=500,
    months_can_store=3
)
# → recommendation: "HOLD 2 MONTHS"
# → expected_gain_kes: 8500 (net of storage costs)
# → confidence: "MODERATE"
# → caveat: "DEMO — based on synthetic seasonal patterns"

What the Model Does

The price model uses three signals:

Seasonal index: Maize prices in Kenya follow a predictable post-harvest depression (March–May) and pre-harvest premium (October–December). This is well-documented in EAGC data.
Regional spread: Nairobi-Nakuru price differentials average 12–18% depending on road conditions and fuel costs. A farmer 200km from Nairobi can calculate whether the transport cost is worth it.
Storage break-even: At KES 500/bag/month, a 15% price increase over 2 months yields KES 7,500 net gain on 50 bags. If expected increase is 8%, don't store — sell now.

Trust Integrity Note

All price data in soko-mcp is DEMO — synthetic data modeled on EAGC seasonal patterns. It does not connect to live market feeds.

Production integration requires:

EAGC API subscription (available to NGOs and research institutions)
NAFIS (National Agriculture and Food Information System) real-time feeds
Kenya National Bureau of Statistics retail price data

The model architecture is production-ready. The data connections are the next step.

Five Tools

pip install soko-mcp

commodity_price_query — current price + 30-day trend
regional_price_comparison — prices across 8 East Africa markets
price_trend_analysis — 12-month historical pattern
sell_hold_decision — net-of-storage recommendation
market_overview — full commodity dashboard

github.com/gabrielmahia/soko-mcp · MIT License

Building parametric crop insurance with wapimaji-mcp and bima-mcp

Gabriel Mahia — Mon, 06 Jul 2026 12:00:00 +0000

Building Parametric Crop Insurance with wapimaji-mcp and bima-mcp

Traditional crop insurance in Kenya requires an adjuster to visit the farm, assess the damage, file a claim, wait for processing, and — maybe — receive a payout months after the harvest has already failed.

Parametric insurance replaces the adjuster with satellite data. If drought reaches Phase 3 in your county, the policy pays out automatically. No adjuster. No waiting. No dispute.

Here's how to build a basic parametric insurance agent using two MCP servers.

The tools

wapimaji-mcp provides Kenya NDMA drought phase classifications across all 47 counties:

# Tool: kenya_county_drought
# Input: county_name
# Output: current drought phase (1-5), affected population, area

bima-mcp provides parametric risk scoring and insurance product matching:

# Tool: parametric_crop_risk
# Input: county, crop_type, area_ha, coverage_amount
# Output: risk score, premium estimate, trigger conditions

The agent workflow

User: "I have 2 hectares of maize in Turkana County. How much will crop insurance cost?"

Agent:
1. wapimaji_mcp.kenya_county_drought(county="Turkana")
   → Phase 4 (Emergency), 67% area affected

2. bima_mcp.parametric_crop_risk(
     county="Turkana", 
     crop_type="maize",
     area_ha=2,
     coverage_amount=50000
   )
   → Risk score: HIGH
   → Estimated premium: KES 4,200/season
   → Trigger: Phase 3+ for 3+ consecutive weeks
   → Payout timeline: 14 days after trigger

Why the combination works

Neither tool alone answers the question. The drought data provides current conditions; the risk tool prices the forward-looking exposure. Together, they give a complete picture in a single agent session.

The farmer gets: a current drought assessment, a premium quote, and the exact trigger conditions — without calling a broker, visiting an office, or waiting for a human intermediary.

This is the practical argument for coordination infrastructure. The data exists. The tools exist. The value comes from connecting them.

Demo data disclaimer

Both tools use synthetic demo data. In production, these would connect to real NDMA APIs and accredited insurance product APIs. The architecture is production-ready; the data sources need to be swapped.

Source code:

What Happens When a Drought Signal Doesn't Go Anywhere

Gabriel Mahia — Fri, 03 Jul 2026 10:00:00 +0000

A smallholder farmer in Turkana County has crop insurance.

The insurance contract is parametric: when rainfall drops 40% below the seasonal mean, the payout triggers automatically. No assessor visit. No claims form. The satellite confirms the threshold, the payment fires.

The rainfall data exists. CHIRPS processes it daily at 0.05° resolution — about 5km grid cells across all of Kenya. The threshold is computable. The payout is automatable.

What doesn't exist: the connection between the data and the contract.

wapimaji-mcp reads the rainfall data. bima-mcp holds the insurance contract. Neither knows the other exists. The drought signal fires into silence.

This is the coordination problem

It's not a data problem. NASA and NOAA publish the data. It's not a model problem — the threshold calculation is simple arithmetic. It's not a deployment problem — both tools run on PyPI.

It's a routing problem. There's no layer that says: when this signal crosses this threshold, notify these tools.

That layer is africa-coord-bus.

What the bus does

pip install africa-coord-bus

When wapimaji-mcp detects drought phase ≥ 2 (Stressed), it publishes:

bus.publish(CoordinationEvent(
    domain=EventDomain.WATER,
    event_type="drought_alert",
    source="wapimaji-mcp",
    severity=EventSeverity.ALERT,
    location=KenyaLocation(county="Turkana", county_code=23),
    data={"ndma_phase": 3, "rainfall_deficit_pct": 42.0},
))

The bus routes this to five downstream tools automatically:

bima-mcp.evaluate_parametric_payout
kilimo-mcp.issue_drought_advisory
soko-mcp.price_alert
afya-mcp.activate_malnutrition_watch
county-mcp.alert_county_health

Six weeks earlier than the current state.

Offline-first

Rural Kenya does not have reliable connectivity. Every event is written to a local queue before dispatch. If dispatch fails, the queue persists. When connectivity restores, the queue replays.

The coordination infrastructure works at the edge.

The gap between data and action

The famine early warning literature has documented this gap for decades. Data exists. Decisions lag. Coordination between the data system and the response system breaks down.

The gap is not technical — it's architectural. No one built the routing layer.

africa-coord-bus is that layer.

Building an Alternative Credit Score from M-PESA Behavioral Data

Gabriel Mahia — Fri, 03 Jul 2026 10:00:00 +0000

FICO was invented in 1956 and took five decades of credit card data to become the global standard. That data simply doesn't exist for most Kenyan adults. But something else does: M-PESA.

35 million Kenyans use M-PESA. Every paybill payment, every savings deposit, every Fuliza loan — that's a behavioral financial record. The question mkopo-mcp asks is: can you build a 300–850 credit score from it?

The Research Basis

The core insight comes from two bodies of work:

Breza & Kinnan (2021): Mobile money adoption in India measurably improved credit access for previously unbanked households. Transaction regularity was a stronger predictor of repayment than income level.

World Bank Financial Inclusion Database (2022): In Sub-Saharan Africa, 57% of adults who use mobile money have never had a formal bank account. That's the population FICO was never designed to serve.

Central Bank of Kenya Prudential Guidelines (2022): CRBs in Kenya are required to report both positive and negative credit information. Fuliza (M-PESA overdraft) data is already flowing to TransUnion Kenya.

The Score Model

from mkopo_mcp import alternative_credit_score

result = alternative_credit_score(
    monthly_income_kes=45000,
    mpesa_transactions_monthly=28,
    avg_transaction_kes=1850,
    paybill_payments_monthly=4,
    fuliza_usage="occasional",
    savings_behavior="regular_deposits",
    phone_tenure_years=3.5,
    months_of_history=18
)
# → score: 647, tier: "FAIR", loan_capacity_kes: 85000

The score is decomposed into four signals:

Signal	Weight	Proxy For
Income regularity	30%	Capacity
Payment consistency	25%	Willingness
Savings behavior	25%	Financial discipline
Tenure + history	20%	Stability

Why Behavioral Signals Work

The intuition: a person who pays their Nairobi Water paybill on time, every month, for 18 months is demonstrating financial discipline that's directly relevant to loan repayment. It's not income — it's behavior.

This is structurally similar to how FICO evolved to include rent payment data (FICO 10T, 2020) and how Experian Boost works in the US — both extend credit scoring to non-traditional signals.

The difference is that in Kenya, those signals are already flowing through one system (M-PESA), not scattered across utilities and landlords.

What mkopo-mcp Doesn't Do

Trust integrity matters here: mkopo-mcp is DEMO infrastructure. It does not connect to real M-PESA transaction data. It models how a score would be computed if such data were available.

Production deployment requires:

User consent for M-PESA transaction access (Safaricom API)
CBK data protection compliance (Data Protection Act 2019)
CRB registration for institutions submitting scores
Actuary-validated model weights (these are illustrative)

The infrastructure exists. The regulatory and data access path is defined. mkopo-mcp demonstrates the model.

The Impact Calculation

If even 10% of Kenya's 30M credit-invisible adults could access microfinance products through alternative scoring:

3M people with access to KES 50,000–200,000 productive loans
At 2% monthly default rate (optimistic) → marginal NPL is manageable
Kenya's MSME financing gap: approximately KES 1.1T (IFC, 2022)

That's not an app. That's coordination infrastructure.

pip install mkopo-mcp

github.com/gabrielmahia/mkopo-mcp · MIT License

How I'm Building MCP Servers for a Language Claude Doesn't Know Well

Gabriel Mahia — Thu, 02 Jul 2026 12:00:00 +0000

How I'm Building MCP Servers for a Language Claude Doesn't Know Well

Swahili has roughly 200 million speakers. It's the primary working language of East Africa. It's a UN official language. And AI models make 4x more errors in Swahili than in English.

That ratio matters when you're building AI tools for people whose primary language is Swahili.

The practical problem

When I test mpesa-mcp with Swahili prompts, the responses are often technically correct but linguistically awkward. Not wrong — just obviously machine-translated from an English-centric internal representation.

For consumer tools (the Streamlit apps — DarajaAI, ShuleAI, KaziAI), this creates friction. The tool is functionally correct but doesn't feel native.

What the data gap actually means

The "4x more errors" figure isn't a model architecture problem. It's a training data problem. English has decades of internet text, books, papers, news, and code. Swahili's written internet corpus is orders of magnitude smaller.

The consequence: models have shallower representations of Swahili concepts, especially domain-specific vocabulary (healthcare, legal, financial). A model that handles "insurance premium" fluently in English may not have seen "bima" (insurance) and "malipo" (premium/payment) co-occurring enough to model the relationship accurately.

How the MCP layer helps

The MCP servers encode domain knowledge structurally, not linguistically. When bima-mcp returns insurance data, the data structure is correct regardless of what language the query came in. The linguistic work happens at the presentation layer — which is more tractable than fixing model weights.

This is one reason the architecture separates tool logic from conversational UI. The tools can be rock-solid even when the Swahili conversation layer is imperfect.

What we're doing about it

The swahili-civic-nlp project (under DPGA review) is building training datasets for Swahili civic vocabulary. The goal is contributing to fine-tuned models that perform better on East African domain tasks.

That's slow work. In the meantime, the MCP tools function as a structural workaround: get the data right first, then improve the language layer.

Progress is possible even with imperfect infrastructure.

What Claude Sonnet 5 Means for AI Infrastructure in East Africa

Gabriel Mahia — Wed, 01 Jul 2026 03:45:51 +0000

What Claude Sonnet 5 Means for AI Infrastructure in East Africa

The release of Claude Sonnet 5 on June 30, 2026 changes something specific about building AI agent infrastructure for regions like East Africa: the model tier that couldn't reliably finish a multi-step workflow now can.

This isn't a general AI update note. It's about a concrete technical constraint that just moved.

The constraint that moved

East Africa's AI infrastructure problem isn't compute or APIs. M-PESA has an API. Africa's Talking has an API. NDMA publishes drought data. KRA has a taxpayer portal. The constraint has been that an AI agent calling several of these in sequence — check drought severity → trigger insurance evaluation → notify county — would stop partway through, lose context, or require manual handholding to continue.

Sonnet 4.6, released in February, scored 67.0% on Terminal-Bench. Sonnet 5, released today, scores 80.4%. That 13-point gap isn't abstract. It's the difference between an agent that stalls at step two of a cascade and one that finishes.

What this means for the East Africa coordination stack

The 31 MCP servers in this portfolio — covering M-PESA, drought data, tax, credit scoring, crop insurance, land records, labor rights, county data, and more — are now meaningfully more useful as a system than they were yesterday.

The key change: africa-coord-bus, the coordination event bus that connects these servers, is now the kind of tool Sonnet 5 was designed to orchestrate. A drought alert from wapimaji-mcp, cascading through bima-mcp for insurance evaluation and county-mcp for notification, is exactly the multi-hop tool chain where the 13-point Terminal-Bench improvement shows up in practice.

The model to use

# Claude API
client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    tools=[...],  # your MCP tools
    messages=[{"role": "user", "content": "..."}]
)

For compliance and vulnerability analysis at the highest accuracy requirement, Opus 4.8 ($5/$25 per MTok) is still the right call. For the coordination and planning work — routing events, calling domain servers, summarizing findings — Sonnet 5 at $2/$10 introductory pricing is the working default now.

A note on the pricing window

The introductory price ($2/$10 per MTok) runs through August 31, 2026. After that it moves to $3/$15. For production deployments with real usage, August is the right time to run load tests and get accurate cost baselines before standard pricing kicks in.

Start here

pip install mpesa-mcp africa-coord-bus — M-PESA + event bus
Connect with claude-sonnet-5 as your agent model
Call get_model_hint() from any server for tested model guidance
Full server list: pypi.org/user/gmahia

Why East Africa Needs Coordination Infrastructure, Not Just AI Apps

Gabriel Mahia — Tue, 30 Jun 2026 10:00:00 +0000

Every conversation about AI in Africa eventually converges on the same framing: "AI for Africa." Apps that use AI. Tools powered by AI. AI everything.

That framing is backwards.

The structural problem East Africa faces isn't a shortage of apps. It's a shortage of the coordination infrastructure that makes economies work. Insurance. Credit scoring. Market price signals. Reputation systems. Civic accountability. Legal access.

These aren't AI features. They're the systems that underpin economic participation everywhere they exist — and their absence is what locks people out of formal economies.

AI is how you deploy them at scale, in Swahili, on $50 smartphones. But AI is the delivery layer. Not the product.

The Five Coordination Failures

Consider what makes a transaction between strangers possible in a mature economy:

1. Uncertainty mitigation → Insurance

Before a farmer plants, they need confidence that one bad season won't destroy them. In Kenya, insurance penetration is 2.3% of GDP. In OECD countries: 8–11%. That gap isn't a wealth gap. It's a missing coordination technology.

2. Trust at a distance → Credit

FICO scores took 50 years of credit card data to build. 70% of Kenyan adults have no formal credit history. But they have M-PESA — a de facto financial ledger of 35M+ people's economic behavior. Credit infrastructure built on M-PESA signals is not a feature. It's a coordination primitive.

3. Information asymmetry → Market intelligence

A farmer in Nakuru doesn't know Nairobi prices are 40% higher this week. The trader knows. That information gap is a direct tax on rural producers, extractable by anyone with a phone and a market visit. Price discovery infrastructure should be public.

4. Trust compression → Reputation

A skilled mason in Mombasa can't take her track record to Nairobi. Trust is tribal and local. Without portable reputation, economic mobility is throttled to your existing network.

5. Enforcement uncertainty → Legal access

40%+ of Kenyans don't know their constitutional rights. Legal aid organizations are chronically underfunded. AI can't replace lawyers — but it can tell a farmer their rights before they're cheated out of their land.

What This Portfolio Builds

Each tool in this stack is one of these coordination technologies, deployed as an open-source MCP server:

Tool	Coordination Problem	PyPI
mpesa-mcp	Payment execution	✅ v0.2.0
bima-mcp	Uncertainty → Insurance	✅ v0.1.0
mkopo-mcp	Trust gap → Credit	✅ v0.1.0
soko-mcp	Info asymmetry → Markets	✅ v0.1.0
sifa-mcp	Trust → Reputation	✅ v0.1.0
civic-agent-kit	Enforcement → Civic rights	✅ v0.2.0
wapimaji-mcp	Environmental risk data	✅ v0.1.2

The AI layer (Gemini, Claude, Llama) makes these accessible through natural language, in Swahili, without requiring technical literacy.

Why MCP Specifically

Model Context Protocol means any AI assistant — Claude, GPT-4, Gemini, local Llama — can call these tools natively. No integration work. Install the package, connect it, and the AI can check NHIF coverage, score a credit application, or compare commodity prices as naturally as answering a question.

That's the leverage point: coordination infrastructure that any AI can use, built by one engineer, available to 47M Swahili speakers.

The Test

When evaluating whether a tool is coordination infrastructure or just an AI app, ask: does this exist as a public, institutional system in developed economies?

Credit scoring → yes (FICO, Equifax, Experian)
Insurance underwriting data → yes (actuarial tables, reinsurance)
Commodity price feeds → yes (Bloomberg, Reuters, CME)
Reputation systems → yes (Yelp, LinkedIn, BBB, Angie's List)
Legal information access → yes (LexisNexis, public court records)

Every yes is a coordination technology East Africa needs. AI delivers it at a fraction of the cost.

Portfolio: gabrielmahia.github.io

All tools: MIT licensed, PyPI-hosted, MCP-compatible.

Africa's MCP Servers Mostly Don't Exist Yet. Here's What Listing One Looks Like.

Gabriel Mahia — Mon, 29 Jun 2026 12:00:00 +0000

Africa's MCP Servers Mostly Don't Exist Yet. Here's What Listing One Looks Like.

Search the largest public registry of MCP servers for "Africa" and the results are thin. Payments, government data, agriculture, health — the domains exist, the institutional APIs exist, but the agent-callable interface to them mostly doesn't.

mpesa-mcp is now indexed in awesome-mcp-servers, the most widely-used community registry, alongside servers for Stripe, GitHub, and PostgreSQL. That's a small fact. The more useful one is what the gap around it looks like.

What's actually listed for the continent

As of this writing, the African-specific entries in that registry are countable on one hand. Meanwhile the registry has hundreds of servers for US and EU financial, government, and SaaS APIs. The asymmetry isn't about demand — M-PESA alone processes a transaction volume most Western payment rails would envy. It's about who's building the connector layer.

What "production-ready" means for this kind of server

Getting accepted into a curated registry forces a specific bar: documented tools, clear scoping (what the server will and won't do), a license, and CI that actually runs. For an MCP server touching financial APIs, two things matter more than usual:

Tool scoping. An agent with mpesa_b2c and mpesa_reversal access needs a PolicyGate-style boundary, not just a docstring. Sandbox-vs-production credentials should be a config flag, not a code branch.
Audit trail. Every financial tool call should be logged with enough context to reconstruct what the agent did and why, independent of whether the underlying transaction succeeded.

The actual gap

mpesa-mcp covers M-PESA. Africa's Talking covers SMS/USSD across 20+ countries. Neither had an MCP interface before this. The pattern repeats across the continent's institutional layer: tax authorities, land registries, health systems, agricultural extension services — each with an API or a data source, none with an agent-native interface.

That's the actual story. Registry listings are a side effect of building the connector; they're not the point.

mpesa-mcp on GitHub · PyPI

The 7-Server Stack: How East Africa's Coordination Infrastructure Works Together

Gabriel Mahia — Thu, 25 Jun 2026 12:00:00 +0000

The 7-Server Stack: How East Africa's Coordination Infrastructure Works Together

I've been building AI infrastructure for East Africa for the past 18 months. Seven MCP servers. Seven coordination failures. One underlying theory.

The theory

Markets fail when participants lack the information to coordinate. In East Africa, the failures are concrete:

A farmer sells maize at harvest when prices are lowest, not knowing Nairobi prices are 40% higher
A small trader can't access credit because their M-PESA history isn't legible to banks
A jua kali welder is paid below market because neither party knows the market rate
A household goes uninsured against drought because parametric products aren't findable

Each of these is an information asymmetry problem. The technology to solve them exists. What's missing is the query layer.

The stack

mpesa-mcp     → payment execution + transaction intelligence
bima-mcp      → insurance products + parametric risk scoring
mkopo-mcp     → alternative credit scoring from M-PESA patterns
soko-mcp      → commodity price intelligence across 8 markets
sifa-mcp      → portable reputation + skills passports
kazi-mcp      → labor market matching + wage benchmarking
wapimaji-mcp  → drought phase data across 47 counties

How they compound

The power isn't any single tool — it's the combinations. An AI agent helping a farmer can simultaneously:

Check current maize price in Nairobi vs local market (soko-mcp)
Assess drought risk for their county (wapimaji-mcp)
Find parametric crop insurance that pays out automatically (bima-mcp)
Check if their M-PESA history qualifies them for input loans (mkopo-mcp)
Verify their reputation score if selling through an aggregator (sifa-mcp)

That's five coordination problems solved in a single agent session. Previously, solving any one of them required navigating multiple institutions, phone calls, and days of waiting.

What's next

The second layer is execution: tools that don't just provide information but actually trigger actions — STK Push payments, insurance policy enrollment, credit applications. Some of that already exists in mpesa-mcp. The rest is coming.

The goal isn't an app. It's infrastructure. Apps are built on top; they can be Swahili-native, SMS-delivered, USSD-based, or voice-first. The coordination layer stays constant.

All seven servers are live on PyPI. All are indexed on the Glama MCP directory. All are MIT-licensed.

pip install mpesa-mcp bima-mcp mkopo-mcp soko-mcp sifa-mcp kazi-mcp wapimaji-mcp