This server provides AI-powered guidance for managing family legal and financial infrastructure in Kenya, covering inheritance, property, and elder care — for both local families and diaspora.
Succession Law Guidance (succession_law_guide): Information on Kenya inheritance rights, intestacy rules, and gender equity under the Law of Succession Act 1972. Accepts an optional situation parameter.
Will Writing Guidance (will_writing_guide): Requirements, costs, and checklist for writing a legally valid will in Kenya.
Diaspora Property Management (diaspora_property_guide): Guidance on managing Kenya property from abroad, covering Power of Attorney (POA), title verification, tax obligations, and remittances. Accepts an optional country parameter (defaults to USA).
Inheritance Dispute Resolution (inheritance_dispute_guide): Resolution paths including family mediation, High Court probate, and Land Disputes Tribunal. Accepts an optional dispute_type parameter.
Caretaker Records Setup (caretaker_records_guide): How to set up formal caretaker arrangements for elderly parents or dependents, including agreements, payment structures, and legal authority.
Trust Structures in Kenya (trust_structures_kenya): Overview of trust structures (discretionary, family, unit trust, chama) for family wealth protection. Accepts an optional use_case parameter.
⚠️ All data is labeled DEMO. Verify with a licensed Kenyan advocate before taking any legal action.
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., "@familia-mcp explain Kenya's inheritance laws for a married couple"
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.
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 familia-mcp · Use with any MCP client.
Kenya family infrastructure via MCP — inheritance, wills, trusts, diaspora property, caretaker records.
pip install familia-mcpRelated MCP server: diaspora-mcp
"Families in Africa often function like corporations. This layer is massively overlooked."
— AI thesis for East Africa, 2026
African families manage inheritance across borders, decades, and generations. The infrastructure to do this well — wills, trusts, caretaker records, diaspora property management — historically required expensive lawyers or was simply absent.
1st world equivalent: LegalZoom Estate Planning / Trust & Will / Fidelity Estate Services
Tool | Function |
| Kenya inheritance rights, intestacy rules, gender equity under Law of Succession Act 1972 |
| Requirements, costs, and checklist for writing a legal will in Kenya |
| POA, title verification, tax, remittance for Kenya diaspora managing property abroad |
| Resolution paths: family mediation, High Court probate, Land Disputes Tribunal |
| Setting up caretaker arrangements for elderly parents — agreements, payment, legal authority |
| Trust structures available in Kenya: discretionary, family, unit trust, chama |
Layer 10: Family Infrastructure ← this server
Layer 9: Civic (habari · mazingira · nyumba)
Layer 7: Financial Rails (mpesa · mkopo · bima · soko · kra · faida)
Layer 6: Identity + Trust (sifa · mkopo)All data labeled DEMO. Verify with a licensed Kenyan advocate before any legal action.
MIT © Gabriel Mahia | contact@aikungfu.dev
This MCP server is one of 32 tools in 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 32 servers: pypi.org/user/gmahia Live demo: coord-cascade-demo
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.
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.
Guide for setting up caretaker arrangements for elderly parents or dependents in Kenya. DEMO.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that this is a read-only guide (likely safe), nor does it describe any side effects or required permissions. The minimal description leaves behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) and front-loaded with purpose. However, the 'DEMO' suffix is unnecessary and could confuse agents. Otherwise, very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema (not shown but exists), the description could be more complete by mentioning what the guide contains (e.g., steps, requirements). Currently it states only a vague purpose. For a simple guide, it's minimally adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. Baseline 4 applies since the description doesn't need to add parameter meaning. It adds no extra semantics, which is acceptable here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a guide for setting up caretaker arrangements in Kenya. The verb 'setting up' and resource 'caretaker arrangements' are specific, and the tool name plus sibling list (e.g., will_writing_guide) help differentiate. However, the 'DEMO' tag is distracting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Sibling tools are listed but no context on selection criteria or exclusions. The description implies it's for caretaker arrangement setup, but no when-not-to-use info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guide for Kenya diaspora managing property and estate from abroad. DEMO.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | USA |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as output format, side effects, or permissions. The minimal description offers no transparency beyond being a guide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but fails to include essential information. It is under-specified rather than genuinely concise, as key details like parameter usage are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and presence of an output schema, the description should provide more context about the guide's content or usage. It lacks completeness for a tool meant to assist users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the purpose or effect of the 'country' parameter. Users have no guidance on how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a guide for Kenya diaspora managing property and estate from abroad. It distinguishes from sibling guide tools by focusing on property/estate management. However, it lacks an active verb and includes 'DEMO', which may confuse purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings. The 'DEMO' label hints at limited real-world use but does not provide clear context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guide to resolving inheritance disputes in Kenya. DEMO.
| Name | Required | Description | Default |
|---|---|---|---|
| dispute_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. Merely says 'Guide... DEMO', lacking details on what happens when invoked (e.g., returns a text guide, displays steps). No contradictions with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence, but the 'DEMO' tag may be superfluous. No structural issues, though could be more informative without lengthening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 should explain what the guide contains and how to use the parameter, but it does neither. The DEMO note suggests incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the sole parameter 'dispute_type'. Does not explain its purpose, expected values, or how it affects the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it provides a guide to resolving inheritance disputes in Kenya. Specific verb 'guide to resolving' and resource 'inheritance disputes in Kenya' clearly indicate the tool's domain. However, the 'DEMO' label reduces clarity about its production readiness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 succession_law_guide or will_writing_guide. Does not specify recommended use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kenya succession law guide — inheritance rights, intestacy rules, gender equity. DEMO.
| Name | Required | Description | Default |
|---|---|---|---|
| situation | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavior. It identifies the tool as a 'guide' and includes 'DEMO', hinting at limited functionality, but does not disclose what the tool actually does when called, any side effects, or the nature of its output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only one line. It is front-loaded with the tool's purpose. However, it omits important details, slightly reducing effectiveness for the sake of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, exists output schema), the description is incomplete. It does not explain the parameter's role, the tool's exact function, or provide enough context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('situation') with no description. The tool description does not mention this parameter or explain when or how to use it. With 0% schema description coverage, the description completely fails to add meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Kenya succession law guide' covering inheritance rights, intestacy rules, and gender equity. While it lacks an explicit action verb, the purpose is evident and distinguishes it from sibling tools which address more specific topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool over the sibling tools (e.g., caretaker_records_guide, will_writing_guide), nor does it specify any prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guide to trust structures available in Kenya for family wealth protection. DEMO.
| Name | Required | Description | Default |
|---|---|---|---|
| use_case | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only or has side effects, nor does it explain the 'DEMO' label. Behavioral traits are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is concise, but the 'DEMO' label could be clarified. It meets conciseness standards without being overly brief to the point of omission.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and one optional parameter, the description lacks context about the output format and the role of 'use_case'. For a guide tool, more detail on the information returned and parameter usage is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'use_case' with 0% description coverage. The description does not explain what 'use_case' expects or how it affects the guide, leaving the agent without guidance on how to set it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a guide to trust structures in Kenya for family wealth protection. It differentiates from sibling tools that cover other legal topics like wills, succession, and inheritance disputes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only implies usage for family wealth protection, but no exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guide to writing a legal will in Kenya. DEMO.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'Guide' and 'DEMO', but does not explain if it returns a template, reads, writes, or requires any prerequisites. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (6 words), which is concise. However, 'DEMO' is arguably unnecessary and reduces clarity, but overall it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's potential legal significance, the description is insufficient. It does not explain what the output contains, whether it is a static reference or interactive, or any limitations. The presence of an output schema partially compensates, but the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100%, fulfilling the baseline for zero-param tools. The description adds no parameter info, which is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a guide for writing a legal will in Kenya, distinguishing it from sibling tools like inheritance_dispute_guide. However, it is very brief and includes 'DEMO' which may confuse the tool's reliability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing a will-writing guide, but lacks explicit guidance on when not to use it or how it compares to siblings. Sibling names provide thematic differentiation but no direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0caretaker_records_guidediaspora_property_guideinheritance_dispute_guidesuccession_law_guidetrust_structures_kenyawill_writing_guideEach tool covers a distinct legal topic (e.g., caretaker arrangements vs. will writing) with clear, non-overlapping descriptions. No two tools appear to serve the same purpose, making selection unambiguous.
All tool names follow a consistent 'topic_guide' pattern using snake_case. The naming is predictable and aligned with the server's theme, facilitating easy identification.
Six tools is a reasonable size for a specialized legal guide server. The count is not excessive nor too thin, though a few additional guides (e.g., marriage or divorce) could be justified.
The server covers core aspects of Kenyan family estate planning: wills, trusts, succession, disputes, diaspora property, and caretaker arrangements. Missing topics like matrimonial property or guardianship are minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Law firm management MCP: manage cases, clients, tasks, calendar and documents via Claude AI.
Governed property-management MCP: portfolio, leasing, accounting, maintenance, OAuth 2.1.
Brazilian legal stack in one MCP: lawsuits, court publications, case law, tenders, certificates.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gabrielmahia/familia-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
