Skip to main content
Glama
deenesjakoruzh
gabrielmahia

wapimaji-mcp

by gabrielmahia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

💧 WapiMaji MCP — 肯尼亚水资源与干旱情报

MCP 服务器，为 AI 智能体提供肯尼亚水资源压力和干旱数据的实时访问权限 — 涵盖全部 47 个县、NDMA 干旱阶段分类，以及通过 Africa's Talking 发送短信提醒的功能。

License: CC BY-NC-ND 4.0 Python 3.10+ MCP

功能概述

WapiMaji MCP 将肯尼亚干旱和水资源压力数据作为 MCP 工具公开。任何 Claude、GPT-4 或兼容 MCP 的 AI 智能体现在都可以：

  • 查询肯尼亚 47 个县中任意一个的实时干旱阶段数据

  • 从 NDMA 干旱监测器获取水资源压力指数

  • 当干旱水平激增时，通过 Africa's Talking 向农民发送短信提醒

单提示词示例：

"What is the current drought phase in Marsabit County?"
→ Gets NDMA Phase 3 classification + rainfall deficit data

"Which counties are in drought emergency right now?"
→ Returns all counties at Phase 3+ with population affected

"SMS these 500 Garissa farmers: drought phase has escalated to 3"
→ Sends alerts via Africa's Talking across Safaricom + Airtel

Related MCP server: DMAP-AI MCP Server

工具

工具

类型

描述

get_drought_status

只读

某县当前的 NDMA 干旱阶段

get_county_water_stress

只读

水资源压力指数、降雨赤字、河流水位

get_drought_alerts

只读

所有处于或高于给定干旱阶段的县

sms_drought_alert

破坏性

通过 Africa's Talking 发送干旱提醒短信

安装

pip install wapimaji-mcp
# or:
uvx wapimaji-mcp

配置

{
  "mcpServers": {
    "wapimaji": {
      "command": "uvx",
      "args": ["wapimaji-mcp"],
      "env": {
        "AT_USERNAME": "your_username",
        "AT_API_KEY": "your_at_key",
        "SANDBOX": "true"
      }
    }
  }
}

数据来源

  • NDMA — 国家干旱管理局干旱阶段分类

  • 肯尼亚气象局 — 降雨数据

  • FEWS NET — 饥荒预警系统粮食安全预测

相关项目

知识产权与合作

© 2026 Gabriel Mahia · contact@aikungfu.dev 许可证：CC BY-NC-ND 4.0 与 NDMA 或 Africa's Talking 无关联。

Available Tools

3 tools
get_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
NameRequiredDescriptionDefault
min_phaseNo

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
NameRequiredDescriptionDefault
countyYes

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
NameRequiredDescriptionDefault
phone_numbersYes
messageYes
sender_idNoWAPIMAJI

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.

  1. 3 tool updatesv0.1.0
    • First observedget_drought_alerts
    • First observedget_drought_status
    • First observedsms_drought_alert
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/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

Resources

Related MCP Connectors

Related MCP Servers

  • mpesa-mcp

    gabrielmahia
    A
    license
    A
    quality
    A
    maintenance
    MCP 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
    126 PyPI
    4
    MIT

  • soko-mcp

    gabrielmahia
    A
    license
    A
    quality
    B
    maintenance
    MCP 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.
    5
    MIT