Loading ToolBench
MCP server for managing a personal life operating system (PARA + GTD + OKR + gamified) with tools for tasks, goals, habits, notes, decisions, achievements, rewards, and AI coaching.
LifeOS MCP server defines 26 read-only tools with consistent naming (verb_noun pattern: get_, list_, search_). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present and typed with enums for constrained parameters (e.g., list_tasks status enum, list_goals status enum). However, parameter descriptions are sparse or missing entirely, most parameters lack explanatory text beyond the name. Output schemas are not documented in the visible code; responses are JSON-stringified but structure is opaque to the LLM. Error handling is absent, no recovery guidance, no categorization. All tools are READ_ONLY (safe), but composition is weak: 26 separate list/get tools with no pagination visible, risking context window exhaustion on large result sets. Tool descriptions are functional but generic ('List X', 'Get X') rather than LLM-optimized with selection context.
Get the user's LifeOS analytics and trend summaries.
Get wallet balances, plan settings, and current financial summary.
Get battle-pass level progress and claim state.
Get today's four generated commissions and completion state.
Get the user's current LifeOS dashboard, priorities, currencies, and progress.
Get wish pool, pity state, fate balance, and recent results.
Parameter descriptions missing or minimal. Most parameters (status, projectId, kind, tag, etc.) lack explanatory text. LLMs cannot infer meaning from names alone, 'status' could mean HTTP status, entity status, or boolean flag. Violates pattern:tool-description baseline (100% of A+ tools have param descriptions).
Output schemas not documented. Tool responses are JSON-stringified but structure is opaque. LLMs cannot plan downstream calls or extract fields without seeing the response schema. Violates pattern:tool baseline (100% of A+ tools have documented return types).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
Get owned rewards, achievements, titles, and equipment inventory.
Read one note or knowledge-base page by exact ID.
Get the note hierarchy, optionally flattened or searched.
Get the computed summary for the current review week.
List achievement definitions and unlock state.
List active life areas and resolve their IDs.
List and filter wallet transactions.
List decision records, optionally filtered by status.
List equipment and the currently equipped frame.
List events, missions, progress, and claim state.
List goals and key results, optionally filtered by status.
List the user's active habits and recent ticks.
List the user's decision and life principles.
List projects and resolve project IDs, optionally filtered by status.
List daily, weekly, monthly, or quarterly reviews.
List the user's reward-shop items.
List active routines and completion state.
List tasks, optionally filtered by status or project.
List titles and the currently equipped title.
Search or filter notes by text, kind, tag, linked entity, or archived state.
No pagination or result limits visible. 26 list/get tools with no limit, offset, or cursor parameters. Large result sets will exhaust context window. Violates pattern:paginated-result baseline (tools returning lists should accept limit and return total count).
No error handling or recovery guidance. Tools have no documented error cases, retryability, or actionable error messages. Violates pattern:recovery-guide (error responses must tell LLM what to do next).
Tool descriptions are generic and lack selection context. Most descriptions are 'List X' or 'Get X' without explaining WHEN to use this tool vs similar ones, or what the LLM should do with the result. Violates pattern:tool-description baseline (descriptions should state WHAT, WHEN, and prerequisites).