What can you do with this server?

The KenyaMCPServer provides access to Kenya's public civic datasets, enabling queries on government data across six tools: * kenya_county_drought: Get the current NDMA drought phase (1=Minimal to 5=Famine) for any of Kenya's 47 counties, in English or Swahili. * kenya_budget_summary: Retrieve county budget allocations, development vs. recurrent spending splits, and absorption rates (FY 2022/23) for a specific county or all 47 at once. * kenya_parliament_bills: Query Kenya Parliament bills (13th Parliament), filtering by legislative status (e.g., Assented, Second Reading, Committee Stage) or by keyword in titles/summaries. * kenya_sacco_lookup: Search the SASRA SACCO registry by name or county, returning details like SACCO type, membership size, total assets, and focus sector. * kenya_rights_query: Query constitutional rights from Chapter 4 of the Constitution of Kenya 2010 (e.g., land, water, health, education) in English or Kiswahili, returning the relevant article and provisions. * kenya_counties_list: List all 47 Kenyan counties, useful as inputs to other tools.

Which integrations are available for this server?

Provides BudgetAgent for county budget analysis using CrewAI framework, enabling AI agents to analyze Kenya's county budget data programmatically. Integrates with DOI system for dataset citation, providing access to Kenya civic datasets with proper academic attribution through DOI identifiers. Integrates with Kaggle datasets, providing access to Kenya civic data including parliament records, county budgets, and SACCO registry information. Distributed as a Python package on PyPI, enabling easy installation and integration of Kenya civic AI tools into Python-based AI agent systems. Built as a Python SDK, providing programmatic access to Kenya civic data and AI tools through Python interfaces for integration with AI agent systems.

How do I use KenyaMCPServer?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KenyaMCPServer show me the drought phases for Turkana county" 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.

de en es ja ko ru zh

KenyaMCPServer

by gabrielmahia

Overview Schema Related Servers Score Discussions

Python

Remote

🛠️ CivicAgentKit — East African Civic AI SDK

civic-agent-kit Glama score

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 civic-agent-kit · Use with any MCP client.

The unified Python toolkit for building civic AI tools in East Africa. One install gives you access to Kenya's parliament records, county budgets, NDMA drought data, M-Pesa payments, and both MCP and A2A protocol integrations.

PyPI License: MIT MCP A2A

Install

pip install civic-agent-kit

Related MCP server: Open Emirates Intelligence

What's included

from civic_agent_kit import (
    # Data loaders — Kenya's public civic datasets
    KenyaBudgetData,       # Controller of Budget — 47 counties
    KenyaParliamentData,   # MPs, bills, CDF — 13th Parliament
    KenyaSACCOData,        # SASRA SACCO registry
    KenyaDroughtData,      # NDMA drought phases

    # Agents
    BudgetAgent,           # County budget analysis (CrewAI)
    RightsAgent,           # Constitutional rights Q&A (EN/SW)
    DroughtAgent,          # Drought + SMS alert agent

    # Protocols
    KenyaMCPServer,        # MCP server — wraps all Kenya data as MCP tools
    KenyaA2AServer,        # A2A server — Kenya civic skills for agent-to-agent

    # Utils
    KenyaCounties,         # All 47 county codes + names
    KiswahiliTranslator,   # Simple civic term translations EN↔SW
)

Quick examples

Load county budget data:

from civic_agent_kit import KenyaBudgetData

budgets = KenyaBudgetData.load()
low_absorption = budgets[budgets['absorption_rate'] < 0.5]
print(low_absorption[['county', 'allocation_kes_m', 'absorption_rate']])

Serve Kenya civic data as an A2A agent:

from civic_agent_kit import KenyaA2AServer

server = KenyaA2AServer(host="http://localhost:8000")
server.run()  # exposes /.well-known/agent.json + JSON-RPC endpoint

Serve as an MCP server:

from civic_agent_kit import KenyaMCPServer

# Run alongside mpesa-mcp for full East African AI stack
server = KenyaMCPServer()
server.run()

Ask a rights question in Kiswahili:

from civic_agent_kit import RightsAgent

agent = RightsAgent(language="sw")
answer = agent.ask("Haki yangu ya ardhi ni nini?")
print(answer)
# → "Kifungu 40: Kila mtu ana haki ya kupata na kumiliki mali..."

The East African AI Stack

                    ┌─────────────────────────────────────┐
                    │         Your AI Agent                │
                    └─────────────┬───────────────────────┘
                                  │
               ┌──────────────────┴──────────────────────┐
               │                                          │
        ┌──────▼──────┐                          ┌───────▼──────┐
        │   MCP Layer  │                          │  A2A Layer   │
        │  (tools)     │                          │  (agents)    │
        └──────┬───────┘                          └───────┬──────┘
               │                                          │
     ┌─────────┴──────────┐                   ┌──────────┴─────────┐
     │                    │                   │                     │
┌────▼────┐        ┌──────▼─────┐     ┌───────▼────┐       ┌──────▼──────┐
│mpesa-mcp│        │KenyaMCP    │     │kenya-a2a   │       │CivicAgent   │
│payments │        │civic data  │     │parliament  │       │Kit agents   │
│SMS      │        │budgets     │     │budgets     │       │budget/rights│
│airtime  │        │parliament  │     │drought     │       │drought      │
└─────────┘        └────────────┘     │rights EN/SW│       └─────────────┘
                                      └────────────┘

Data

All data from the Kenya Civic Datasets (CC BY-SA 4.0):

Kaggle: gmahia/kenya-civic-data — DOI: 10.34740/kaggle/dsv/15473045
HuggingFace: gmahia/kenya-civic-data — DOI: 10.57967/hf/8223

Package	Description	PyPI
`mpesa-mcp`	M-Pesa + Africa's Talking MCP server
`civic-agent-kit`	This package

Full portfolio

13 deployed civic apps: gabrielmahia.github.io

IP & Collaboration

Protocol Coverage — Complete Stack

civic-agent-kit now supports all four major AI agent protocols for East Africa:

Protocol	What it does	Implementation
MCP	Agent → Tool	mpesa-mcp, wapimaji-mcp
A2A	Agent → Agent	kenya-a2a
Google ADK	Agent orchestration	kenya-adk
AG-UI	Agent → Frontend	kenya-agui

Each protocol layer above was implemented within weeks of its global release — because the coordination gaps these tools address don't wait for tooling maturity.

from civic_agent_kit import CivicAgentKit

# Full protocol stack
kit = CivicAgentKit(
    mcp_servers=["mpesa-mcp", "wapimaji-mcp"],  # MCP
    a2a_registry="kenya-a2a",                    # A2A
    agui_server="kenya-agui",                    # AG-UI
    adk_config="kenya-adk",                      # Google ADK
)

Part of the East Africa coordination stack

Install & run: pip install reli-cli && reli list — 33 MCP servers on the official MCP Registry under io.github.gabrielmahia
Evaluate 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 tools

kenya_budget_summaryKenya County Budget SummaryA

Read-onlyIdempotent

Get county budget allocation, development vs recurrent split, and absorption rate. FY 2022/23 data from Kenya Controller of Budget. DEMO data — real data: opendata.go.ke and cob.go.ke.

ParametersJSON Schema

Name	Required	Description	Default
`county`	Yes	County name, or ALL for all counties
`language`	No	en or sw	en

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 indicate read-only, non-destructive, and idempotent behavior. The description adds critical context: the data is from FY 2022/23, sourced from the Kenya Controller of Budget, and is DEMO data (not real). This goes beyond annotations and is valuable for an agent.

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 three short, front-loaded sentences. The first states the purpose, the second gives the source, and the third notes it is demo data. Every sentence adds value with no redundancy.

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 a simple query tool with an output schema, the description explains what data is retrieved and its demo nature. Minor gap: could mention that the language parameter affects output, but the schema description covers it. Overall adequate.

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 the description does not add meaning beyond the schema. The description mentions 'county budget allocation' which ties to the county parameter, but does not elaborate on formats or allowed values. 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 uses a specific verb 'Get' and clearly identifies the resource: county budget allocation, development vs recurrent split, and absorption rate. It distinguishes this tool from siblings like kenya_counties_list (county names) and kenya_county_drought, as it focuses on budget data.

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?

The description implies when to use (to get budget data) but provides no explicit guidance on when not to use it or alternatives. It does not mention siblings or suggest using kenya_counties_list for county names or kenya_county_drought for drought information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kenya_counties_listKenya Counties ListA

Read-onlyIdempotent

List all 47 Kenya counties. Returns names suitable for use with other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds value beyond annotations by specifying the exact number of counties (47) and the output nature (names suitable for other tools), enhancing transparency.

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 efficient sentences that front-load the action and purpose without unnecessary detail.

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?

Given the tool's simplicity, the description fully covers purpose, output, and usage context, especially with annotations and output schema available.

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?

With no parameters, description adds context about return values (names), which is helpful for invocation.

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?

Description clearly states verb 'list' and resource 'all 47 Kenya counties', distinguishing it from sibling tools that focus on specific data like budget or drought.

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?

Description indicates use with other tools, implying it's a foundational list. While no explicit when-not-to-use, the simplicity and sibling context make it clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kenya_county_droughtKenya County Drought StatusA

Read-onlyIdempotent

Get current NDMA drought phase for any of Kenya's 47 counties. Phase 1=Minimal, 2=Stressed, 3=Crisis, 4=Emergency, 5=Famine. Data source: Kenya National Drought Management Authority (NDMA). DEMO data — for real-time data see ndma.go.ke.

ParametersJSON Schema

Name	Required	Description	Default
`county`	Yes	Kenya county name e.g. Turkana, Garissa, Nairobi
`language`	No	Response language: en (English) or sw (Swahili)	en

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by stating the data source (NDMA) and that data is DEMO, which is helpful context beyond annotations.

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 highly concise: four short sentences that front-load the purpose, then add phase meaning, data source, and demo warning. No unnecessary words.

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?

With an output schema, return values are covered. The description explains data source, demo nature, and suggests an alternative for real-time data. Missing minor details like case sensitivity of counties, but overall adequate for a simple read-only 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?

Schema coverage is 100%, so baseline is 3. The description adds example county names (Turkana, Garissa, Nairobi) and mentions language options (en/sw), which helps parameter understanding beyond the schema.

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 retrieves the current NDMA drought phase for any of Kenya's 47 counties, specifies the meaning of phases (1=Minimal, etc.), and distinguishes itself from sibling tools like kenya_budget_summary or kenya_counties_list by focusing on drought data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly notes that the data is DEMO and suggests using ndma.go.ke for real-time data, providing clear guidance on when to use this tool versus an alternative source.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kenya_parliament_billsKenya Parliament BillsA

Read-onlyIdempotent

Query Kenya Parliament bills and their legislative status. Returns bills with title, status, type, date and summary. DEMO data — real data: parliament.go.ke.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter: All, Assented, Second Reading, Committee Stage, First Reading	All
`keyword`	No	Search keyword in bill title or summary

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 (readOnlyHint=true, idempotentHint=true) align with the query nature. Description adds value by noting data is DEMO and real data is at parliament.go.ke, which is crucial for agent expectations.

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: purpose, returned fields, and demo data disclaimer. No wasted words, 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?

Tool has two simple parameters, output schema exists (context signal), and description mentions return fields. Demo data disclaimer provides completeness. Slight gap: no mention of pagination or limits, but acceptable for simplicity.

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?

Input schema has 100% coverage, describing status and keyword. Description does not add new parameter-level details beyond listing return fields. 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?

Description clearly states the tool queries Kenya Parliament bills and their legislative status, listing returned fields. This distinguishes it from siblings like kenya_budget_summary and kenya_counties_list.

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?

No explicit when-to-use or when-not-to-use guidance. Context from sibling tools implies scope, but description lacks direct guidance on alternatives or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kenya_rights_queryKenya Constitutional Rights Q&AA

Read-onlyIdempotent

Query Kenya constitutional rights from Chapter 4 of the Constitution of Kenya 2010. Returns the specific constitutional article and its provisions. Works in English and Kiswahili.

ParametersJSON Schema

Name	Required	Description	Default
`right`	Yes	Right to query: land/ardhi, water/maji, health/afya, education/elimu, labour/kazi, housing/nyumba, food/chakula
`language`	No	en (English) or sw (Swahili)	en

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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows it's a safe, repeatable read. The description adds that it returns specific article and provisions, and supports two languages, which provides useful behavioral context beyond annotations.

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 sentences, each serving a purpose: purpose, output, language support. No redundant words. Front-loaded with the key action and resource.

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 presence of an output schema, the description does not need to detail return values. It covers the source (Chapter 4), output type, and language support. Lacks mention of specific rights list, but the parameter description covers that. Adequate for a simple query 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 description coverage is 100%, so the input schema already explains parameters. The description adds that the tool works in English and Swahili, aligning with the language parameter, but does not add significant new meaning beyond what the schema provides. 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 verb 'Query', the specific resource 'Kenya constitutional rights from Chapter 4', and the output 'returns the specific constitutional article and its provisions'. It distinguishes itself from sibling tools like kenya_budget_summary by focusing on constitutional rights, and mentions bilingual support.

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?

The description implies usage for querying constitutional rights, but does not explicitly state when to use vs alternatives, nor provides exclusions or conditions. The sibling tools are unrelated, but no direct guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kenya_sacco_lookupKenya SACCO LookupA

Read-onlyIdempotent

Look up Kenya SACCOs from the SASRA registry. Returns name, type, membership, assets, county and focus sector. DEMO data — real registry: sasra.go.ke.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	SACCO name or partial name to search, or ALL	ALL
`county`	No	Filter by county

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, destructiveHint, and idempotentHint. The description adds a critical behavioral trait: the data is DEMO and to get real data one should visit the actual registry. No contradiction.

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?

Three sentences: purpose, returned fields, and data source note. Front-loaded and concise, though the purpose and fields could be combined slightly more efficiently.

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 lookup tool with annotations fully covering safety, an output schema exists (so return values are documented), and parameters are well-described. The description is complete for the tool's complexity.

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 has 100% coverage with descriptions for both parameters. The description does not add additional meaning beyond what the schema provides (e.g., that 'name' can be a partial match or 'ALL'). Baseline score of 3 applies.

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 action ('Look up Kenya SACCOs'), the resource ('SACCOs from the SASRA registry'), and lists the returned fields. It is distinct from sibling tools which cover different topics.

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 specifies the source (SASRA registry) and notes that the data is DEMO, implying when to use the tool. It does not explicitly state when not to use it, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool addresses a distinct domain (budget, counties, drought, parliamentary bills, constitutional rights, SACCOs). There is no overlap in purpose, and agents can easily distinguish between them.

Naming Consistency5/5

All tools follow a consistent 'kenya_<domain>_<operation>' pattern, using snake_case. The naming is predictable and easy to understand.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose of providing Kenya-specific data. Each tool offers meaningful functionality without unnecessary bloat.

Completeness4/5

The tool set covers multiple important Kenya-related domains, but there are minor gaps such as missing education, health, or demographic data. However, the current selection is sufficient for many use cases.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Public Data Ukraine Mcp A
io.github.varvararatta
Public Data Ukraine Mcp connects AI agents to real public APIs via MCP. Tools include
Government Data Open Data
52
ToolAPI B
org.toolapi
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Agent Orchestration Autonomous Agents
19322
Airbyte Agents
io.github.airbytehq
Let AI agents query data and act across all your business apps via MCP.
Data Platforms AI & Machine Learning RAG Systems
2
databazaar
io.github.shagarwal
Agent-first data marketplace — AI agents search, purchase, and sell datasets via MCP.
Research & Data AI & Machine Learning Autonomous Agents
2

Related MCP Servers

county-mcp
Government Data Open Data
gabrielmahia
A
license
C
quality
A
maintenance
Provides access to Kenya 47-county local government data, including demographics, budgets, services, and contact information for all counties.
Updated 2 months ago (2026-07-18 23:29 UTC)
6
MIT
Open Emirates Intelligence
Government Data Open Data
zad-tools
A
license
Not graded
quality
A
maintenance
Provides queryable access to official UAE open data through MCP tools, resources, and prompts, with bilingual support and multiple data connectors.
Updated 11 days ago (2026-08-24 01:09 UTC)
24
2
MIT
chile-procurement
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables access to Chile's government procurement data (Mercado Público / ChileCompra) via MCP, allowing AI agents to query public procurement information.
Updated 8 days ago (2026-08-26 16:47 UTC)
13
MIT
mcp-colombia-secop
Government Data Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables AI agents to query Colombian government procurement data via MCP tools or natural language questions.
Updated 8 days ago (2026-08-26 16:49 UTC)
12
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/civic-agent-kit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🛠️ CivicAgentKit — East African Civic AI SDK

Install

What's included

Quick examples

The East African AI Stack

Data

Related packages

Full portfolio

IP & Collaboration

Protocol Coverage — Complete Stack

Part of the East Africa coordination stack

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API