A
licenseA
qualityA
maintenanceMCP server for East African fintech APIs — trigger M-Pesa STK Push payments, check transaction status, send SMS to 20+ African networks, and top up airtime via Africa's Talking.
5
42 PyPI
4
MIT
wapimaji-mcp
by gabrielmahia
This server provides AI agents with real-time access to Kenya's NDMA drought data and SMS alert capabilities across all 47 counties:
Get drought status for a specific county (
get_drought_status): Query the current NDMA drought phase (1=Minimal to 5=Famine) for any Kenyan county, including rainfall deficit percentage and affected population.Get drought alerts across multiple counties (
get_drought_alerts): Retrieve all counties at or above a specified drought phase threshold (default: Phase 3/Crisis) to identify regions in widespread drought emergency.Send SMS drought alerts (
sms_drought_alert): Send real SMS messages via Africa's Talking to lists of phone numbers (E.164 format) with custom messages and a sender ID. Supports sandbox mode for testing before sending to live recipients (Safaricom, Airtel, etc.).
💧 WapiMaji MCP — Kenya Water & Drought Intelligence
Compatible with claude-sonnet-5 (released 2026-06-30) — Anthropic's most agentic
Sonnet yet. Runs multi-step tool chains end-to-end without stopping short.
Install: pip install wapimaji-mcp · Use with any MCP client.
A Kenya drought-response toolkit for AI agents: simulated county drought phases (no real NDMA data is integrated yet), SMS alerts through Africa's Talking that need explicit confirmation, and drought events published to the coordination bus.
What it does, and does not
Simulated drought phases for the 47 counties. Values are generated from the county name so downstream flows can be built and tested. They are not observations and not NDMA data; every answer says
"synthetic": true. Never use them for decisions.No real data source is integrated. With
SANDBOX=falsethe status tools return an explicit "not implemented, status unknown" error. NDMA publishes drought phases as periodic bulletins; FEWS NET and IPC publish food-security classifications through APIs that were slow or unverified when checked on 2026-10-07. Integrating one is the next step.SMS alerts through Africa's Talking: simulated by default (
sent: false); a live send needsSANDBOX=falseandconfirm_send=true.Coordination: publish a drought event so downstream MCP servers (insurance, agriculture advisory, health, county alerts) can react.
Related MCP server: DMAP-AI MCP Server
Tools
Tool | Type | Description |
| Read-only, simulated | A simulated drought phase for one county, labelled synthetic |
| Read-only, simulated | Simulated list of counties at or above a phase |
| Sends SMS | Send a drought alert SMS via Africa's Talking (needs |
| Writes an event | Publish a drought coordination event for downstream servers |
Install
pip install wapimaji-mcp
# or:
uvx wapimaji-mcpConfigure
{
"mcpServers": {
"wapimaji": {
"command": "uvx",
"args": ["wapimaji-mcp"],
"env": {
"AT_USERNAME": "your_username",
"AT_API_KEY": "your_at_key",
"SANDBOX": "true"
}
}
}
}Data sources
Runtime safety and data limits
SANDBOX=true (the default) uses simulated county drought values, including
aggregate alerts. These values are not observations from NDMA. Live aggregate
alerts are not implemented and return an explicit error with unknown status.
SMS calls in sandbox return sent: false without contacting Africa's Talking.
Live SMS requires both SANDBOX=false and confirm_send=true, supplied only after
the user explicitly confirms that send. Provider acceptance does not establish
delivery to the recipient.
No real data source is integrated. Earlier versions listed NDMA, the Kenya Meteorological Department and FEWS NET here; the code never used them.
Related
mpesa-mcp — M-Pesa + Africa's Talking MCP server
WapiMaji — The Streamlit dashboard version
gabrielmahia.github.io — Full civic portfolio
IP & Collaboration
© 2026 Gabriel Mahia · contact@aikungfu.dev License: MIT Not affiliated with NDMA or Africa's Talking.
Related datasets
Earlier versions said this server draws on NASA MODIS NDVI, NOAA CHIRPS, TRMM and FEWS NET; it does not read any of them. The Hugging Face datasets africa-open-climate-data and east-africa-agricultural-pd are separate resources.
Part of the East Africa Coordination Stack
This MCP server is part of the Kenya coordination infrastructure.
Connect it to africa-coord-bus —
the coordination event bus that routes signals between domains automatically.
pip install africa-coord-busAll servers: pypi.org/user/gmahia Live demo: coord-cascade-demo
Part of the East Africa coordination stack
Install & run:
pip install reli-cli && reli list— the MCP servers on the official MCP Registry underio.github.gabrielmahiaEvaluate 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
3 toolsget_drought_alertsB
Get all Kenya counties at or above a given drought phase. min_phase: 1=Minimal, 2=Stressed, 3=Crisis, 4=Emergency, 5=Famine
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| min_phase | No |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the function (read counties) and explains the phase parameter. Does not disclose read-only nature, rate limits, data freshness, or any constraints beyond basic purpose.
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: first states purpose, second explains the sole parameter. No redundancy, front-loaded with key action, and efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain what is returned (e.g., array of county names or objects). Missing details on empty results, errors, or pagination. For a simple tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates by defining the integer parameter values: '1=Minimal, 2=Stressed, 3=Crisis, 4=Emergency, 5=Famine'. This adds necessary context beyond the schema's 'Min Phase' title and type.
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?
Clearly states 'Get all Kenya counties at or above a given drought phase', specifying exact verb and resource. Distinguishes from siblings: 'get_drought_status' likely for single county, 'sms_drought_alert' for sending alerts. No confusion with other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_drought_status' or 'sms_drought_alert'. Does not mention prerequisites or context for invocation. Agent must infer based on name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_drought_statusA
Get current NDMA drought phase classification for a Kenya county. Returns drought phase (1=Minimal to 5=Famine), rainfall deficit %, and population affected. county: Kenya county name e.g. Turkana, Marsabit, Garissa
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| county | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses return values (drought phase scale, rainfall deficit, population affected). It does not mention authorization or side effects, but for a read-only get operation, this is adequate.
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 two sentences plus a parameter line, front-loading purpose and return format. Every sentence adds value with zero waste.
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 no output schema, the description explicitly lists return fields (phase, deficit, population). It also distinguishes from siblings. Missing details like error handling or rate limits, but these are not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no description for 'county'). The description adds meaningful context: 'county: Kenya county name e.g. Turkana, Marsabit, Garissa', clarifying the parameter's domain and providing examples.
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 gets current NDMA drought phase classification for a Kenya county, specifying the resource and scope. It distinguishes from siblings 'get_drought_alerts' and 'sms_drought_alert' by focusing on status vs alerts.
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 implies use for current status queries, and examples of counties guide parameter input. While it doesn't explicitly state when not to use or mention alternatives, the purpose is clear enough for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sms_drought_alertA
Send a drought alert SMS via Africa's Talking. DESTRUCTIVE — sends real SMS in production. Use SANDBOX=true for testing. phone_numbers: list of E.164 format numbers e.g. ["+254712345678"] message: SMS text (max 160 chars) sender_id: registered AT sender ID
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| phone_numbers | Yes | ||
| message | Yes | ||
| sender_id | No | WAPIMAJI |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Highlights destructive side effect ('sends real SMS in production') and sandbox option, but does not cover other behaviors like rate limits, costs, or failure modes.
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?
Very concise: three sentences with purpose, warning, and parameter meanings. No wasted words, information is front-loaded.
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?
For a simple SMS sending tool, the description covers purpose, parameters, and destructive behavior. Missing return value description, but given no output schema, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds valuable details beyond the schema: phone_numbers format (E.164), message max length (160 chars), and sender_id requirement. Schema only provides basic types.
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?
Clearly states 'Send a drought alert SMS via Africa's Talking.' Uses specific verb (send) and resource (SMS), and distinguishes from sibling tools (get_drought_alerts, get_drought_status) which are read-only.
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?
Explicitly warns about destructive nature and provides sandbox testing guidance. However, lacks explicit alternatives or when-not-to-use conditions.
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.
3 tool updates
v0.1.0- First observed
get_drought_alerts - First observed
get_drought_status - First observed
sms_drought_alert
TDQS
A4/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a distinct purpose: retrieving counties by drought phase, getting detailed status for a specific county, and sending an SMS alert. There is no overlap or ambiguity.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern, but 'sms_drought_alert' uses 'sms' as a verb while 'get_drought_alerts' and 'get_drought_status' use 'get'. This minor inconsistency prevents a perfect score.
Tool Count5/5
With only 3 tools, the server is tightly scoped to its purpose of drought alerting for Kenya. Each tool earns its place and the count is appropriate for the domain.
Completeness4/5
The tool set covers core needs: querying alerts, detailed status, and sending alerts. Minor gaps like listing all counties or historical data exist but are not critical for the primary use case.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
African intelligence infrastructure for AI apps, developers, and data products via MCP.
An MCP server that through www.gdacs.org provides access to web‐based disaster information systems.
MCP server for the GDEX (Geoscience Data Exchange) data portal: datasets, files, metrics, subsetting
The Mobile Text Alerts SMS MCP server enables your AI to send SMS messages & manage contacts
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceMCP server for DMAP-AI drought monitoring and SPI drought analysis using NASA POWER and ERA5-Land/CDS data.-
- AlicenseAqualityBmaintenanceMCP server for East Africa commodity price intelligence — regional price comparison across 8 markets, trend analysis, and sell/hold decision support for smallholder farmers. 5 tools.524 PyPIMIT
- AlicenseCqualityAmaintenanceMCP server for Kenya environment — NEMA permits, climate data, conservation areas, environmental rights, climate adaptation.5MIT