Loading ToolBench
MCP server for portable reputation and skills passports in East Africa
Server has 6 tools with complete input schemas and descriptions. Naming follows verb_noun convention (create_worker_profile, add_service_record, get_worker_profile, generate_reference, skill_categories, list_profiles). Descriptions are detailed and contextual (100-250 chars), exceeding baseline minimums. All parameters have type annotations and descriptions. However, output schemas are not explicitly documented in the code, return types are inferred from implementation logic rather than formally declared. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool annotations present (readOnlyHint, destructiveHint) but incomplete coverage. No pagination support on list_profiles despite demo note acknowledging it should be paginated in production.
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.
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.
Generate a portable, shareable reference letter from a worker's verified service records. Western parallel: LinkedIn recommendation, Upwork portfolio review, professional reference letter. Can be shared as text, QR code, or PDF.
Retrieve a worker's full reputation profile including service history, trust score, and verification status. Western parallel: viewing a LinkedIn profile, Uber driver rating card, Angie's List contractor page.
List all worker profiles in the system (demo only). In production, this would be paginated and filtered. Returns profile IDs, names, skills, locations, and current trust scores.
Output schemas not formally documented. Return types inferred from implementation (e.g., _trust_score returns dict with 'total_score', 'tier', 'breakdown', 'tier_description') but not declared in tool definitions. LLMs cannot plan downstream calls without knowing response structure.
list_profiles lacks pagination (limit, offset, page_size parameters). Code comment states 'In production, this would be paginated and filtered' but demo implementation returns all profiles unbounded. No total_count or next_cursor in response structure.
No error handling or recovery guidance. Tools do not validate inputs (e.g., years_experience 0-40 constraint not enforced, skill validation against SKILL_CATEGORIES not visible in tool code). No error messages guide LLM on what to do if profile_id is invalid or skill is unrecognized.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
List available skill categories and sub-skills. Use this to validate skill inputs when creating profiles. Categories include construction, transport, domestic, tech, agriculture, food, health, education, business.
Tool annotations incomplete. create_worker_profile and add_service_record marked with readOnlyHint=False, destructiveHint=False, but these are WRITE operations (create, add), should be destructiveHint=True or use idempotentHint. Annotations do not accurately reflect tool semantics.
Profile ID generation uses SHA256 hash of name+phone but phone is described as 'not stored in plain text', however, phone is passed as parameter and hashed deterministically. No actual privacy protection; hash is reversible via brute force. Security claim in docstring is misleading.