A
licenseA
qualityC
maintenanceMCP server for AgentFolio — the identity and reputation layer for AI agents. Query agent profiles, trust scores, verification status, and marketplace listings through 8 MCP tools.
9
134
1
MIT
sifa-mcp
by gabrielmahia
The sifa-mcp server provides a portable reputation and skills passport system for workers in East Africa, solving the problem of non-portable professional identity by digitizing and centralizing reputation. Key capabilities include:
Create Worker Profiles: Build a portable "economic passport" capturing a worker's name, phone, primary skill, sub-skills, location, experience, and languages — generating a unique profile ID (e.g.,
SFA-A3F2B19C4E1D).Log Completed Jobs: Record service engagements with client details, service type, duration, payment (in KES), and a 1–5 star rating — each record contributes to the worker's trust score.
Retrieve Reputation Profiles: Fetch a worker's full profile including a computed trust score (0–100) and tier (
NEW,BUILDING,ESTABLISHED,TRUSTED), tailored to the requester context (employer, bank, SACCO, NGO, etc.).Generate Reference Letters: Produce structured professional references for job applications, loan applications, tenancy, SACCO membership, or NGO programme enrollment.
Browse Skill Categories: Explore all available NITA-aligned skill categories and subcategories for use when creating profiles.
Compare Workers: Rank and compare multiple workers side-by-side by trust score and skill match for a specific job requirement.
⭐ sifa-mcp — Portable Reputation & Skills Passport 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 sifa-mcp · Use with any MCP client.
Sifa = reputation/praise in Swahili.
Informal-sector workers build reputation with one buyer, one platform, one neighborhood at a time — and lose it the moment they switch. Nothing makes that reputation portable or agent-queryable.
The Structural Problem
In mature economies, reputation travels: Uber driver ratings, Yelp reviews, LinkedIn endorsements, contractor licence registries. A skilled plumber in Chicago can prove her track record to any homeowner in Los Angeles.
In Kenya, trust is tribal and local. A qualified mason in Mombasa cannot take her reputation to Nairobi. Economic mobility is throttled by the non-portability of professional identity.
Reputation portability is a coordination technology. Without it, hiring defaults to personal networks, which excludes the most talented people outside existing networks.
Related MCP server: AgentStamp
Tools
Tool | What it does |
| Create a portable reputation profile with skills, location, experience |
| Log a completed job with client details and rating |
| Retrieve full profile with trust score for any requester type |
| Generate a formatted professional reference letter |
| Browse all NITA-aligned skill categories |
| Rank multiple workers by trust score and skill match |
Trust Score
Scored 0–100 across four signals:
Job volume (up to 30 pts) — number of completed jobs
Average quality (up to 35 pts) — client star ratings
Verified records (up to 20 pts) — client-OTP-confirmed completions
Tenure (up to 15 pts) — years of documented history
Tiers: NEW → BUILDING → ESTABLISHED → TRUSTED
Quick Start
pip install sifa-mcp # coming soon to PyPI
sifa-mcp # starts on stdioExample
# Create a mason's portable profile
create_worker_profile(
full_name="James Mwangi",
phone="0712345678",
primary_skill="construction",
sub_skills="masonry,tiling,plastering",
location="Nairobi",
years_experience=8
)
# → SFA-A3F2B19C4E1D
# Log a completed job
add_service_record(
profile_id="SFA-A3F2B19C4E1D",
client_name="ABC Contractors",
client_phone="0722000000",
service_type="Kitchen tiling",
duration_days=5,
payment_kes=15000,
client_rating=5
)
# Generate a reference for a new job application
generate_reference(profile_id="SFA-A3F2B19C4E1D", reference_purpose="job_application")Research Basis
IFC "The Value of Reputation" (2020)
ILO Skills Recognition Framework (2023)
World Bank "Mobile-Based Reputation Systems" (2021)
Kenya NITA (National Industrial Training Authority) trade classifications
⚠️ DEMO — Production requires Huduma Number / NIIMS integration for identity verification.
© 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.
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
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 toolsadd_service_recordA
Add a completed service record to a worker's profile. Western parallel: Uber trip completion, Angie's List job review, Upwork completed contract. Each record builds the reputation score. DEMO — client verification is simulated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | Worker profile ID (SFA-XXXXXXXXXXXX format) | |
| client_name | Yes | Client name (or business name) | |
| client_phone | Yes | Client M-PESA number (for verification anchor) | |
| service_type | Yes | Type of service performed | |
| duration_days | Yes | Duration of the job in days | |
| payment_kes | Yes | Amount paid in KES (0 if unpaid/pro bono) | |
| client_rating | Yes | Client rating 1-5 stars | |
| notes | No | Brief description of work done |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation. Description adds that each record builds reputation score and notes demo simulation, which adds some behavioral context beyond annotations but not extensive.
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 short sentences, front-loaded with purpose. No wasted words; efficient and clear.
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?
Output schema exists, so return values are documented. Description mentions reputation impact and demo context. Could mention prerequisites like profile existence but overall complete.
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 description adds no extra parameter meaning. 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 it adds a completed service record to a worker's profile. The western parallels and sibling list differentiate it from 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 explicit guidance on when to use vs alternatives. The description provides analogies but no when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_workersARead-only
Compare the reputation scores of multiple workers for a specific job. Western parallel: Contractor comparison on Thumbtack, Bark, or Houzz. DEMO data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| profile_ids | Yes | Comma-separated list of profile IDs to compare | |
| required_skill | No | Skill required for the job |
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?
Annotations already declare readOnlyHint=true, ensuring the agent knows it's a safe read operation. The description adds value by revealing 'DEMO data', indicating results are simulated—a crucial behavioral trait 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a parallelism line). The 'DEMO data' is essential and front-loaded. The extra Thumbtack/Bark/Houzz mention is somewhat extraneous but not wasteful. Slightly more structure could improve readability, but it's efficient overall.
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 an output schema (not shown), the description need not detail return values. It sets clear expectations (comparing reputation scores). The 'DEMO data' caveat addresses data authenticity. However, it might be improved by noting the number of profiles allowed (e.g., max 5?). Overall, sufficiently complete for a simple read-only comparison 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 schema sufficiently documents both parameters. The description adds minimal semantic value beyond the schema: it reinforces that comparison is 'for a specific job', aligning with the 'required_skill' parameter. No extra format or constraint details are provided, 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 'Compare the reputation scores of multiple workers for a specific job', which is a specific verb and resource. It distinguishes from sibling tools like 'get_reputation_profile' (likely single worker) and 'create_worker_profile' (creation). The Western parallel adds context without obscuring purpose.
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 explicit guidance on when to use this tool versus alternatives (e.g., when to compare vs. using 'get_reputation_profile' for a single worker). The 'DEMO data' hint suggests it may be for testing only, but this is not clearly stated as a usage constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_worker_profileA
Create a portable worker reputation profile. Western parallel: LinkedIn profile creation, Angie's List contractor profile. This is the 'economic passport' that travels with the worker. DEMO — no real identity verification in this prototype.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| full_name | Yes | Worker's full name | |
| phone | Yes | M-PESA phone number (used as identity anchor, not stored in plain text) | |
| primary_skill | Yes | Primary skill category (see skill_categories tool) | |
| sub_skills | Yes | Comma-separated list of specific skills (e.g., 'masonry,tiling,plastering') | |
| location | Yes | Current base location (town or county) | |
| years_experience | Yes | Years of experience in primary skill (0-40) | |
| languages | No | Languages spoken (e.g., 'Swahili,English,Kikuyu') | Swahili |
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 provide basic safety info (not read-only, not destructive). The description adds context: 'portable', 'economic passport', and the DEMO nature with no real identity verification. It could mention what happens if profile already exists.
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 plus a note, front-loaded with key purpose. The analogies are helpful without being verbose. Every sentence adds value.
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's complexity and presence of output schema, the description covers core purpose and demo limitation. It could improve by noting relationships to sibling tools (e.g., adding records later).
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 no additional parameter semantics needed. The description adds no new parameter info beyond what's in 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 uses specific verb 'Create' and resource 'worker reputation profile'. It provides cultural analogies (LinkedIn, Angie's List) that clarify the purpose and distinguish it from sibling tools like add_service_record or get_reputation_profile.
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 states when to use: to create a portable reputation profile, with a demo note indicating prototype limitations. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_referenceARead-only
Generate a structured professional reference letter for a worker. Western parallel: LinkedIn recommendation, employer reference letter. Outputs a formatted reference that can be printed, shared as PDF, or verified by QR code in production. DEMO.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | Worker profile ID | |
| reference_purpose | No | Purpose: job_application, loan_application, tenancy, SACCO_membership, NGO_programme | job_application |
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?
Adds context beyond annotations: outputs formatted reference for printing, PDF, or QR verification, and notes 'DEMO' mode. Annotations already indicate readOnlyHint=true, which is consistent.
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?
Two sentences with key info, but 'DEMO' is ambiguous (demo mode vs production). Generally concise.
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?
Covers purpose, output format, verification mechanism. With output schema present, no need to detail return values. Adequate for a simple two-parameter 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 descriptions for both parameters. The description does not add extra meaning beyond 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 generates a structured professional reference letter for a worker, with parallels like LinkedIn recommendations. It distinguishes from sibling tools that handle service records, worker profiles, etc.
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?
Provides context with Western parallels suggesting typical use cases (e.g., job application). However, no explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reputation_profileARead-only
Retrieve a worker's full reputation profile including trust score. Western parallel: Checking a contractor's BBB rating or Upwork JSS. DEMO data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | Worker profile ID to retrieve | |
| requester_context | No | Who is requesting (employer, SACCO, bank, NGO) | employer |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description only adds the DEMO data note. No behavioral details beyond that, but 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?
Two sentences; the first is direct and functional. The second adds an analogy and data quality note, which is slightly extraneous but not wasteful.
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 and full parameter descriptions in the input schema, the description adequately covers context, especially with the DEMO clarification.
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 already fully describes both parameters (profile_id and requester_context) with clear descriptions. Description adds no further semantic value 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?
Description clearly states 'Retrieve a worker's full reputation profile including trust score', which is a specific verb and resource. It distinguishes well from sibling tools like add_service_record or compare_workers.
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 explicit guidance on when to use this tool versus alternatives, nor any when-not conditions. The DEMO mention hints at context but lacks directive advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_skill_categoriesARead-only
List all skill categories and subcategories available in the Sifa system. Use this to see valid skill values for create_worker_profile.
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?
Description adds that it lists both categories and subcategories, beyond the readOnlyHint annotation. No contradictions. For a parameter-less read tool, 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?
Two short sentences, no redundant information. Every word contributes to understanding.
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 zero parameters and presence of an output schema, the description is complete. It explains what the tool returns and why to use it.
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?
No parameters, so baseline is 4. Description adds value by explaining the output's purpose (valid skill values for another tool).
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 it lists all skill categories and subcategories in the Sifa system. The mention of create_worker_profile provides context for its use.
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 says to use this tool to see valid skill values for create_worker_profile, giving clear usage context. No exclusions or comparisons to siblings, but sufficient for the simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: creating profiles, adding service records, comparing workers, generating references, retrieving profiles, and listing skill categories. No two tools overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., create_worker_profile, get_reputation_profile, list_skill_categories). The naming is uniform and predictable.
Tool Count5/5
With 6 tools, the set is well-scoped for a reputation management system. Each tool covers a core operation without unnecessary bloat or deficiency.
Completeness4/5
The tool set covers essential operations (CRUD on profiles, records, comparisons, references). Missing update/delete operations for profiles and records are minor gaps given the demo nature.
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
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
LinkedIn outreach MCP server — 19 tools for AI agents to prospect, sequence, and manage contacts.
Related MCP Servers
- AlicenseAqualityDmaintenanceTrust intelligence MCP server for AI agents. 19 tools for identity stamps, reputation scoring (0-100), agent registry, forensic audit trails, ERC-8004 bridge, and A2A passports via x402 USDC micropayments.191Apache 2.0
- AlicenseAqualityAmaintenanceMCP server for alternative credit scoring in Kenya — builds a 300–850 score from M-PESA behavioral signals for adults with no formal credit history. 5 tools.5MIT
- AlicenseAqualityAmaintenanceMCP 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.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/sifa-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server