Flint Notes MCP provides 7 tools with complete input schemas and non-trivial descriptions. Tool naming follows verb-noun convention (list_, search_, read_, create_, edit_, delete_, get_). All tools have descriptions (10-194 chars) and input parameters are typed with descriptions. However, there are significant gaps: (1) no output schemas documented, (2) parameter descriptions lack format/constraint details, (3) edit_note has undocumented mutually-exclusive parameter behavior, (4) error handling is basic (tool handlers return ok/err helpers but no recovery guidance), (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having mixed risk levels (READ_ONLY, WRITE, REVERSIBLE, DESTRUCTIVE). Descriptions are adequate but not LLM-optimized, they lack dependency hints, prerequisite context, and what-to-do-next guidance. Parameter validation is strict at runtime but the schema/descriptions do not communicate constraints clearly (e.g., 'limit' must be positive, 'week' format is ISO week).
Create a new Flint note in the current ISO week folder.
Delete a Flint note. confirm must be true.
Edit an existing Flint note. Provide exactly one of content (full replacement) or append (add to end).
Get Flint status: notes directory, current week, note counts.
List notes from Flint. Returns title, path, modified (ISO date), preview, source, and type for each note.
Read the full content of a Flint note by title or path.
Full-text search across all Flint notes.
No output schemas documented. Callers cannot know what fields to expect from tool responses, forcing them to guess at the structure and plan downstream calls blindly. Critical for LLM tool composition.
edit_note has mutually exclusive parameters (content vs append) but this is documented only in the description, not in the schema. No oneOf constraint or clear parameter dependency documentation. LLMs may pass both and cause ambiguous failures.
No tool annotations. Tools span READ_ONLY, WRITE, REVERSIBLE, and DESTRUCTIVE operations, but the schema does not declare readOnlyHint, destructiveHint, or idempotentHint. LLMs cannot determine which calls are safe to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Parameter descriptions lack format/constraint details. 'week' accepts ISO week format (e.g. '2026W12') but the schema only says 'Filter by ISO week, e.g. "2026W12".', example, not constraint. 'limit' must be positive but description says 'Max notes to return. Must be a positive integer.', the constraint is in prose, not a JSON Schema minimum.
Error handling returns ok/err helpers but does not guide recovery. No actionable error messages that tell LLMs what to try next. E.g., if a note is not found, the error could suggest 'Use search_notes() to find the note by content.'
Parameter descriptions do not include dependency hints. E.g., read_note accepts 'title' or 'path' but the description does not explain when to use which or how to obtain them.