Skip to main content
Glama
deenesjakoruzh
gabrielmahia

wapimaji-mcp

by gabrielmahia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

💧 WapiMaji MCP — 케냐 물 및 가뭄 인텔리전스

AI 에이전트가 케냐의 물 부족 및 가뭄 데이터(47개 카운티 전체, NDMA 가뭄 단계 분류)에 실시간으로 액세스하고, Africa's Talking을 통해 SMS 알림을 보낼 수 있게 해주는 MCP 서버입니다.

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

기능

WapiMaji MCP는 케냐의 가뭄 및 물 부족 데이터를 MCP 도구로 제공합니다. 이제 Claude, GPT-4 또는 MCP 호환 AI 에이전트는 다음을 수행할 수 있습니다:

  • 케냐 47개 카운티의 실시간 가뭄 단계 데이터 조회

  • NDMA 가뭄 모니터의 물 부족 지수 확인

  • 가뭄 수준이 급증할 때 Africa's Talking을 통해 농부들에게 SMS 알림 발송

원 프롬프트 예시:

"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을 통해 가뭄 알림 SMS 발송

설치

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 — 국가 가뭄 관리국(National Drought Management Authority) 가뭄 단계 분류

  • 케냐 기상청(Kenya Meteorological Department) — 강우량 데이터

  • 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