A
licenseC
qualityA
maintenanceMCP server for Kenya environment — NEMA permits, climate data, conservation areas, environmental rights, climate adaptation.
5
MIT
bima-mcp
by gabrielmahia
The bima-mcp server provides Kenya-specific insurance intelligence tools (using DEMO/synthetic data for educational purposes):
kenya_insurance_products: List IRA-registered insurance product categories and representative products, filterable by type (health, life, crop, device).nhif_coverage_query: Look up NHIF (National Hospital Insurance Fund) benefits by hospital tier (Level 2–6) and procedure type (inpatient, outpatient, maternity, renal, cancer, mental health).premium_estimate: Estimate monthly premiums for health, life, crop, or device insurance based on age, income, county, and other parameters.parametric_crop_risk: Calculate satellite-based (NDVI/NDMA) crop insurance risk scores for smallholder farmers by county, crop type, acreage, and season.compare_microinsurance: Compare affordable microinsurance options for low-income Kenyans, filtered by target group (informal worker, farmer, student, elderly, refugee) and monthly budget.community_pool_calculator: Size and plan a group pooled insurance arrangement for chama savings groups based on member count, contributions, and coverage goal (hospitalization, funeral, crop loss, education).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@bima-mcpWhat crop insurance is available for maize farmers in Nakuru?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🛡️ bima-mcp — Kenya Insurance Intelligence MCP Server
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 bima-mcp · Use with any MCP client.
Insurance products exist — NHIF, parametric crop cover, microinsurance — but comparing them or checking eligibility requires navigating separate portals with no shared interface.
Exposes Kenya insurance data, NHIF coverage analysis, parametric crop risk scoring, and microinsurance comparison through the Model Context Protocol.
Why Insurance Infrastructure Matters
In mature economies, insurance is invisible infrastructure — it enables risk-taking by capping downside. A farmer plants a new crop because crop insurance limits loss. A parent starts a business because health insurance protects the family. Without this floor, the rational choice is perpetual caution.
Kenya's insurance penetration: 2.3% of GDP vs 8–11% in developed markets. The gap is not cultural — it is the cost of distribution, claims verification, and actuarial data. All three can be compressed by technology.
Related MCP server: usafiri-mcp
Tools
Tool | What it does |
| List IRA-registered products by type (health, life, crop, device) |
| Query NHIF benefits by hospital tier and procedure type |
| Estimate monthly premiums for any coverage type + income bracket |
| NDMA-based crop insurance risk for smallholder farmers |
| Compare affordable products by target group and budget |
| Size a chama pooled insurance arrangement |
Quick Start
pip install bima-mcp # coming soon to PyPI
bima-mcp # starts the MCP server on stdioClaude Desktop Integration
{
"mcpServers": {
"bima-mcp": {
"command": "bima-mcp"
}
}
}Use Cases
Farmers: "What crop insurance do I need for my 2-acre maize farm in Nakuru?"
Informal workers: "What NHIF tier 4 inpatient coverage do I get for KES 500/month?"
Chama treasurers: "How do I set up pooled hospitalization cover for 25 members?"
Researchers: "Compare parametric crop insurance risk across Kenya counties"
Research Basis
ACRE Africa Parametric Crop Insurance Methodology (2023)
Kenya IRA Annual Report 2024
World Bank Insurance Primer for Low-Income Markets (2023)
NDMA County Drought Monitoring Reports
⚠️ Disclaimers
DEMO data — not real insurance products or binding quotes. Not affiliated with NHIF, IRA, or any insurance provider. Always consult a licensed IRA-registered insurance agent for actual products. Kenya IRA: ira.go.ke
© 2026 Gabriel Mahia / AI Kung Fu LLC · MIT License
Part of the East Africa Coordination Stack
This MCP server is one of 32 tools in the Kenya coordination infrastructure.
It connects to africa-coord-bus — the coordination
event bus that routes signals between domains automatically.
When this server detects a threshold condition, the bus notifies:
bima-mcp— parametric insurance evaluationkilimo-mcp— agricultural advisoryafya-mcp— health surveillance activationcounty-mcp— county office alert
pip install africa-coord-busAll servers: pypi.org/user/gmahia
IP & Collaboration
MIT licensed. Feedback via GitHub Issues only — pull requests are not accepted. Demo data is labeled DEMO and is not suitable for operational decisions. Full policy: docs/architecture/IP_POLICY.md. Security reports: see SECURITY.md.
Part of the East Africa coordination stack
Install & run:
pip install reli-cli && reli list— 33 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
6 toolscommunity_pool_calculatorARead-only
Calculate parameters for a community group (chama) pooled insurance arrangement. Western parallel: Fraternal benefit societies, mutual insurance companies, credit unions with insurance. Kenya parallel: Chama savings groups can formalize as Micro Insurance Groups under IRA. DEMO educational tool — not a licensed insurance product.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| group_size | Yes | Number of chama members (5–200) | |
| monthly_contribution_kes | Yes | Monthly contribution per member in KES | |
| coverage_goal | No | Coverage goal: hospitalization, funeral, crop_loss, education | hospitalization |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares it as a 'DEMO educational tool — not a licensed insurance product,' which goes beyond the readOnlyHint annotation to warn about non-production use. It also provides parallel examples, adding context about its educational nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of core purpose, followed by two sentences of useful context and a warning. It is front-loaded and efficient, though the parallel examples could be trimmed without losing key information.
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?
The description covers the tool's purpose, educational nature, and regulatory context. With an output schema available, it does not need to detail return values. It is sufficiently complete for a calculation tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters. The description adds no new meaning beyond the schema, so it scores the baseline of 3.
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 'Calculate parameters for a community group (chama) pooled insurance arrangement.' It uses a specific verb and resource, and the mention of Western and Kenya parallels helps distinguish it from sibling tools like premium_estimate or compare_microinsurance, which focus on different aspects.
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?
The description provides cultural context but no explicit guidance on when to use this tool versus its siblings. It does not specify scenarios where other tools are more appropriate or caution against misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_microinsuranceARead-only
Compare available microinsurance options for low-income Kenyans. Western parallel: Insurtech comparison platforms (Policygenius, The Zebra, NerdWallet Insurance). East Africa context: 67% of Kenyans cannot afford conventional insurance premiums. DEMO data — verify products at ira.go.ke.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target_group | No | Target group: informal_worker, farmer, student, elderly, refugee | informal_worker |
| max_monthly_budget_kes | No | Maximum monthly premium budget in KES |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description adds value by warning that data is DEMO and advising verification at ira.go.ke, which informs the agent about data reliability beyond the annotation's safety flag.
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?
Three concise sentences, front-loaded with the core purpose, followed by helpful context. No redundant words, every sentence earns its place.
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 the tool has 2 parameters, full schema coverage, and an output schema, the description adequately covers purpose, target audience, and data source. It is fairly complete, though could briefly mention how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes both parameters (target_group and max_monthly_budget_kes) with defaults. The description adds no additional parameter-specific meaning, so baseline 3 is appropriate.
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 compares microinsurance options for low-income Kenyans. It distinguishes itself from sibling tools like community_pool_calculator and kenya_insurance_products by specifying its focus on microinsurance comparison.
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 provides context (Western parallel, East Africa context) indicating when to use: for comparing microinsurance for low-income Kenyans. It does not explicitly exclude cases or mention alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kenya_insurance_productsARead-only
List Kenya insurance product categories and representative products. Returns DEMO synthetic data for educational/research purposes. Not real insurance products or binding quotes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| product_type | No | Filter by type: health, life, crop, device, or 'all' | all |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds important context that the data is DEMO synthetic and not real, which is beyond what annotations provide.
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, front-loaded with the main action, and contains no unnecessary words. Every sentence serves a purpose.
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 the simple schema, output schema existence, and one parameter, the description covers the core purpose and data nature. It is complete enough for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter description is already fully defined in the schema. The tool's description adds no additional meaning or usage context for the filter options.
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 verb 'List' and the resource 'Kenya insurance product categories and representative products', which is specific and distinguishes it from sibling tools like compare_microinsurance or premium_estimate that perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for educational/research purposes by noting it returns synthetic data, but lacks explicit guidance on when to use this tool against siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nhif_coverage_queryARead-only
Query NHIF (National Hospital Insurance Fund) coverage details by hospital tier and procedure. NHIF is Kenya's state health insurer, analogous to Medicare in the US or NHS in the UK. DEMO data — verify at nhif.or.ke.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Hospital tier: level_2, level_3, level_4, level_5, level_6 | level_4 |
| procedure_type | No | Procedure type: inpatient, outpatient, maternity, renal, cancer, mental_health | inpatient |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, description adds behavioral context: data is demo, verification required at nhif.or.ke. No contradiction, valuable beyond annotation.
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 adds analogies and data warning. No wasted words, front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with two parameters, output schema present, annotations declare read-only. Description adds demo data context. Complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. Description mentions 'by hospital tier and procedure' but does not add significant new meaning beyond schema. Baseline 3 appropriate.
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?
Clear verb 'Query', resource 'NHIF coverage details', and scope 'by hospital tier and procedure'. Additional context about NHIF as state insurer and demo data distinguishes from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use (query coverage), but lacks explicit exclusions or alternatives to sibling tools. The demo data warning implies caution but is not a strong usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parametric_crop_riskARead-only
Calculate parametric crop insurance risk for a Kenya smallholder farmer. Based on ACRE Africa methodology: NDVI satellite index + NDMA drought history. Western parallel: Root Insurance telematic scoring, Skywatch EasyCrop satellite insurance. DEMO data — actual payouts require enrollment with a licensed insurer.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| county | Yes | Kenya county name (e.g., Nakuru, Turkana, Machakos) | |
| crop | Yes | Crop type: maize, beans, potatoes, wheat, sorghum, millet, cassava, tea, coffee | |
| acreage | Yes | Farm size in acres | |
| season | No | Farming season: long_rains (Mar-May) or short_rains (Oct-Dec) | long_rains |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no destructive behavior. The description adds context about the methodology (NDVI satellite index, NDMA drought history) and clarifies the demo nature, which goes beyond the annotation. No contradictions.
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?
Four sentences with no wasted words. The first sentence states the purpose, followed by methodology and a critical limitation. Front-loaded and easy to parse.
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?
The description covers purpose, methodology, and the demo limitation. With an output schema present, it does not need to describe return values. It could mention what happens with invalid inputs or missing seasons, but overall it is adequate for a non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description provides context about Kenya farming and satellite indexes but does not elaborate on the individual parameters beyond what the schema already gives. Baseline score of 3 is appropriate.
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 verb 'Calculate' and the resource 'parametric crop insurance risk' for a specific user (Kenya smallholder farmer). It distinguishes from sibling tools that deal with community pools, microinsurance comparisons, products, NHIF, and premium estimates.
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 explicitly notes that the tool uses DEMO data and actual payouts require enrollment, which helps set expectations. However, it does not explicitly tell the agent when to use this tool versus alternatives like 'premium_estimate' or 'community_pool_calculator', though the purpose is sufficiently distinct.
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. Dates show when Glama detected each change.
6 tool updates
v0.1.0- First observed
community_pool_calculator - First observed
compare_microinsurance - First observed
kenya_insurance_products - First observed
nhif_coverage_query - First observed
parametric_crop_risk - First observed
premium_estimate
TDQS
A4/5.0
Disambiguation5/5
Each tool targets a distinct aspect of insurance in Kenya: community pool, microinsurance comparison, product listing, NHIF coverage, parametric crop risk, and premium estimation. No functional overlap.
Naming Consistency4/5
Tool names are descriptive and use underscores consistently, but patterns vary (verb_noun, noun_noun, adjective_noun). Minor inconsistency, still clear.
Tool Count5/5
Six tools is well-scoped for an educational insurance demonstration server—neither too few nor too many.
Completeness3/5
Covers key areas like comparison, estimation, and specific products, but lacks full lifecycle (e.g., policy purchase, claims). Suitable for demo/research but not complete for real-world agent workflows.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
保险产品搜索、推荐、保费试算、核保预检。覆盖65家保司483款产品。China insurance MCP server.
MCP server for medicare-coverage
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseBqualityAmaintenanceMCP server for Kenya transport — matatu route finder, NTSA services, boda licensing, freight logistics, passenger rights.5MIT
- AlicenseBqualityAmaintenanceMCP server for Kenya health system — NHIF/SHA coverage, facility finder, community health workers, maternal health guidance, essential medicines.6MIT
- AlicenseBqualityAmaintenanceMCP server for Kenya land administration — title search, land rates, subdivision process, dispute resolution, land rights.5MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gabrielmahia/bima-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server