An MCP server for managing notes stored in a SQLite database with add, list, and search functionality
The NotesManager server provides three basic tools with minimal documentation. All three tools have schemas with proper JSON types and descriptions, which is the baseline. However, descriptions are extremely brief (8-34 characters), parameter descriptions are generic, and there is no output schema documentation. Error handling is absent, tools return plain strings with no guidance for recovery or retry logic. The tool names follow verb_noun convention (add_note, list_notes, search_notes) but lack depth in their descriptions. Missing: pagination controls, output schema documentation, error classification, recovery guidance, idempotent operation hints, and composition guidance. The server implements basic CRUD without acknowledging the 54 agentic patterns or the needs of LLM-based agents.
Add a new note to the database.
List all notes in the database.
Search for notes by title or content.
Tool descriptions are under 20 characters and provide no context for LLM selection. 'Add a new note to the database.' (34 chars) and 'List all notes in the database.' (31 chars) lack detail on WHEN to use each tool, what distinguishes them, or what they return. These descriptions fall below actionable thresholds.
No output schema documented. Tools return plain text strings (e.g. 'Successfully added note: {title}', 'Notes List:\n- [id] title...'), not structured objects. LLMs cannot parse output reliably or chain results to downstream tools. list_notes returns a formatted string; agents cannot extract note IDs or counts without parsing unstructured text. search_notes returns concatenated results, agents cannot programmatically iterate or extract typed fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
list_notes has no pagination controls. The tool returns ALL notes in the database formatted as a single string. No limit, offset, page_size, or cursor. If the database grows to 1000+ notes, the entire list is returned untruncated, wasting tokens and degrading LLM reasoning.
No error handling or recovery guidance. If add_note receives a title that is empty or oversized, the tool silently fails or crashes. If search_notes finds no results, it returns a plain string 'No notes found matching \'query\'.', not a structured error with retry guidance.
add_note modifies state (INSERT) but has no confirmation step, dry-run, or idempotent hint. If an agent retries a failed add_note call, it creates duplicate notes.
Parameter descriptions are minimal. 'title' is described as 'The title of the note.' and 'content' as 'The body content of the note.', generic, no constraints (length, format, required fields). 'query' in search_notes is 'The search term.', no indication of case sensitivity, min length, regex patterns, or how fuzzy matching works.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). list_notes and search_notes are read-only but unmarked; add_note is destructive (creates records) but unmarked. Per current MCP spec (2026-07-28), tool annotations are a standard pattern for helping agents reason about side effects and idempotency.
No composition guidance. If an agent wants to 'find a note and add a comment', no guidance exists on chaining tools. The tool set is minimal (only CRUD on notes), so composition risk is low, but for a multi-domain server, chaining would be hard without documented IDflows and reference fields.