Loading ToolBench
Local-first MCP server giving AI agents contextual knowledge about the people in your life
The server defines 8 tools for managing people and relationship context. Tools 1-4 have explicitly visible schemas in the source (openclaw-plugin/src/index.ts), while tools 5-8 are referenced but lack visible schema definitions in the provided code. This creates a significant visibility problem: 50% of tools cannot be fully evaluated. Of the visible tools, descriptions are present but generic (ranging 100-150 chars), parameter types are defined in JSON Schema, but lack detailed constraints and dependency documentation. Tool naming follows verb_noun convention (resolve_person, get_person_context, remember_person) which is good. However, parameter descriptions are often minimal. Error handling strategy and output schema documentation are not evident in the code samples. The server is local-first (SQLite backend, STDIO transport) with reasonable separation of concerns across tools, but lacks the polish expected of production-grade agent tools.
Find the relationship path between two people.
Return traits, friction history, reminders, and the user's communication philosophy for a person.
Return a minimal-disclosure context bundle for a known person.
Record a durable fact, affiliation, or relationship about someone in one audited transaction.
Create or update a person record, including aliases and summary.
Resolve a name, nickname, or partial reference to one or more known people.
Search for people by name, relationship, organization or other attributes.
Tools 5-8 (search_people, remember, stage_candidates) lack visible schema definitions in source code. Only file paths are listed without actual parameter/output schemas. This violates the critical rule: if schema is not visible, score must be 0.
Tool 'remember' is too generic a name. Does it create a new person record, update existing data, or both? Lacks verb_noun clarity. Compare against 'remember_person' (tool 4) which is clearer. Pattern guidance: tool names should start with specific action verbs (create, update, record).
Tools 5-8 lack explicit descriptions in the provided source snippets. Without descriptions, LLMs cannot determine when or why to select these tools. This violates: 'Every tool must have a non-empty description.'
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2025-06-18+ | v2 |
Stage concise structured proposals for later user review without committing automatically.
Parameter 'hints' in resolve_person accepts object type but lacks detailed documentation of which hint combinations are valid/recommended. Undocumented interdependencies between org, role, relationship hints force the LLM to guess. Pattern guidance: document parameter relationships explicitly.
Output schemas are not documented for any of the 8 tools. LLMs need to know what fields to expect in responses so they can chain tool calls and extract data correctly. Absence of documented return types prevents effective tool composition.
No error handling guidance visible in tool descriptions. Tools like 'remember_person' (WRITE) and 'remember' (WRITE) should document recovery paths for failure cases (e.g., duplicate name, validation errors). Error responses should tell the LLM what to do next.
Parameter 'purpose' in get_person_context has default 'communication' but no enum of valid values is documented. What other purposes are valid? Is 'scheduling' valid as the description suggests? LLM may hallucinate invalid values.
Tool 'find_connection' accepts only person_id but no documentation of what 'connection' means (direct relationship, transitive path, graph distance, depth limit). Does it return the full path? Just the connection type?