Local MCP server that exposes CairnOS services (projects, tasks, ideas, notes, reminders) over stdio. Allows Claude Code to read and modify the user's productivity data through tools, backed by a local SQLite database.
CairnOS MCP server has 13 well-named tools with consistent verb_noun patterns (create_, update_, get_, search_, mark_, classify_, summarize_). All tools have descriptions (avg ~100 chars, within baseline 34-392 range). Input schemas are present and typed for all tools. However, output schemas are NOT documented, critical gap for LLM planning. Parameter descriptions are present but often minimal (e.g., 'Task id' lacks format/constraint details). No tool annotations (readOnlyHint/destructiveHint). Error handling is basic, no recovery guidance or actionable error messages visible in schema. Composition is strong: tools chain well (e.g., search_items → get_project_context), and natural identifiers (project name or id) are accepted. Missing: pagination for list-like tools (get_today_tasks, get_overdue_tasks, get_active_projects return unbounded results), output schema documentation, and error recovery patterns.
Run the CairnOS rule-based classifier on messy text and return structured, reviewable items (tasks, ideas, reminders, notes, projects) without saving them.
Create a new project with an optional objective, description, priority, and color.
Create a reminder that fires at the given ISO-8601 time.
Create a new task. Optionally attach it to a project (by name or id), set a priority and an ISO-8601 due date.
List all active projects.
List open tasks whose due date has passed.
Return the full structured context of a project (by id or name): the project plus all its tasks, notes, ideas, reminders, progress, and next action.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., task_id from create_task, project_id from create_project). This forces agents to guess response structure.
List tools (get_today_tasks, get_overdue_tasks, get_active_projects) lack pagination (limit, offset, cursor) and total count. Unbounded results risk context window exhaustion and degrade LLM reasoning.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without explicit hints. All WRITE tools should have destructiveHint=true.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
List open tasks due today.
Mark a task as completed by id.
Full-text search across tasks, projects, ideas, notes, and reminders.
Return a concise text summary of a project (by id or name): progress, next action, and counts.
Update fields of an existing project by id.
Update fields of an existing task by id. Only provided fields are changed.
Parameter descriptions lack format/constraint details. E.g., 'Task id' does not specify format (UUID, integer, string pattern). 'ISO-8601 date string' is good, but 'Hex color code (#RRGGBB)' should be a regex pattern in schema. LLMs cannot validate without explicit constraints.
No error handling guidance. Tools lack recovery hints (e.g., 'Project not found. Try search_items() to find the project name.'). Agents cannot self-correct on failures.