MCP server for Subnotes. Reads notebook files and writes inbox files; it never touches SwiftData. The app owns every store access — a second process writing to a CloudKit-mirrored store is the failure mode this project has already spent five rounds on.
Subnotes has clear, action-oriented tool names (list_notebooks, read_notebook, add_task, add_tasks) and reasonable descriptions (avg ~100 chars). However, critical gaps undermine production readiness: input schemas lack type declarations for most parameters (e.g., 'priority' and 'section' in add_task have no enum constraints despite documented valid values), parameter descriptions are sparse or missing entirely (subnotes array has no description), and output schemas are completely undocumented. Error handling exists but is generic. The server reads/writes files safely but lacks the structured, LLM-optimized definitions expected of production tools.
Adds a single task to a notebook with optional priority, section, and subnotes.
Adds multiple tasks to a notebook in a single operation.
Lists all connected notebooks with their purposes, open task counts, and sections.
Reads the full content of a notebook file by name.
Input schemas lack type constraints and enums. 'priority' parameter accepts 'Today|Next|Soon|Someday' (documented in code as PRIORITIES array) but schema shows no enum constraint. LLMs will hallucinate invalid values.
Output schemas completely undocumented. Tools return unstructured text (e.g., 'Lists all connected notebooks...') with no field definitions. LLMs cannot extract structured data or chain calls reliably.
Parameter descriptions missing or incomplete. 'subnotes' array in add_task has description 'Array of subnote strings to attach to the task' but no guidance on format, length limits, or examples. 'section' parameter lacks description entirely in add_tasks.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
No error recovery guidance. UserError messages are user-facing (e.g., 'No connected notebook called...') but lack actionable next steps for LLMs. Should suggest 'Call list_notebooks() to see available options.'
No pagination or result limits documented. read_notebook returns entire file contents with no truncation guidance. Large notebooks could exhaust context windows.