A FastMCP server for managing notes, tasks, categories, and providing AI-powered productivity features with Gemini integration
Lightspeed MCP exhibits significant quality gaps across naming, descriptions, and schema completeness. While tool names generally follow verb_noun conventions, descriptions vary widely in quality, some tools (e.g., create_note, delete_note) lack sufficient specificity about side effects and consequences. Parameter descriptions are present but often generic ('Optional MCP Context' repeated across all tools). Schemas are partially specified with type information visible, but many parameters lack detailed constraints, ranges, or enum definitions. The server includes 31 tools with mixed quality: image processing tools (1-6) are reasonably well-described but image examples tools (7-9) rely on deprecated sampling/roots patterns. AI and productivity tools (10-12) have vague descriptions and expose implementation details (ctx parameter) that should be internal. Task and notes tools (19-30) are structured consistently but descriptions don't clarify mutability or error recovery paths. Critical issue: the 'ctx' parameter appears across nearly all tools as optional but is sometimes required for functionality (e.g., simulate_long_image_processing, list_image_files_in_root), creating ambiguity for LLM tool selection. No tool includes error handling guidance or destructive operation confirmation patterns.
Generate a caption for an image using the LLM (delegated to client via ctx.sample).
Chat with the AI assistant using Gemini.
Mark a task as completed (status = done).
Convert an image to a different format (e.g., jpeg, png).
Create a new category for organizing notes.
Create a new note with the given title and content.
Create a new task with the given title and description.
Context parameter (ctx) exposed in tool signatures across 20+ tools with unclear optionality and undocumented behavior. Some tools claim it's optional but functionality degrades without it (e.g., llm_caption_with_sampling, simulate_long_image_processing, list_image_files_in_root). This internal implementation detail should not leak into the tool API surface.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Create a thumbnail from an image file and return as Image object.
Delete a note by ID.
Delete a task by ID.
Extract basic metadata from an image file.
Find potential duplicate notes based on title and content similarity.
Use AI to analyze notes and suggest tasks that should be created.
Retrieve all categories for the user.
Get a summary of all categories with note counts.
Retrieve notes for the user.
Get all notes that belong to a specific category.
Generate a comprehensive productivity dashboard with notes and tasks analytics.
Get task statistics (count by status) for the user.
Retrieve tasks for the user, optionally filtered by status.
Convert an image to grayscale.
Use AI to enhance and improve the content of a specific note.
List image files in a directory, respecting roots access (client must allow).
Generate an image caption by requesting a completion from the client LLM.
Assign a note to a category (organize note).
Resize an image to the specified width and height.
Search notes by content or title.
Simulate a long-running image processing task with progress updates.
Use AI to summarize the user's notes, optionally filtered by category.
Update an existing note.
Update an existing task.
Destructive operations (delete_note, delete_task) lack error handling guidance, confirmation patterns, and explicit descriptions of irreversible consequences. No dry-run or undo mechanisms documented. LLMs cannot reason about recovery paths.
Parameter descriptions are often single short phrases ('User ID (default: demo-user)', 'Optional MCP Context') without explaining what the tool actually does with the parameter or when it matters. Examples: improve_note_content says 'Type of improvement (grammar, clarity, expansion, etc.)' without defining which types are valid or what happens if an invalid type is passed.
Tools relying on deprecated MCP patterns: llm_caption_with_sampling and caption_image use ctx.sample() (server-initiated sampling, deprecated in favor of direct LLM integration). simulate_long_image_processing uses ctx.report_progress() (progress reporting not in current spec). list_image_files_in_root references ctx.roots (roots deprecated). These tools will break when the MCP spec removes these patterns (~2027-07-28).
No parameter validation constraints visible in schemas. 'improvement_type' in improve_note_content accepts a string with a description hinting at valid values (grammar, clarity, expansion) but no enum defined. 'similarity_threshold' in find_duplicate_notes describes a number between 0 and 1 but no min/max constraints visible. LLMs will guess at valid values and fail if they pass 2.5 or 'typo'.
Many read operations (get_notes, get_categories, get_tasks) accept 'skip' and 'limit' parameters but no guidance on pagination behavior, maximum limits, or what happens when a user requests page 1000. No return of total_count or next_cursor to support reliable pagination.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). Modern MCP spec allows marking tools with semantic hints so clients can warn before executing destructive operations or highlight that a tool is read-only. Missing for all 31 tools.
No visible output schema documentation for any tool. Responses are described as strings or simple types ('str', 'dict', 'list[str]') but without documenting the actual shape of objects returned. Example: extract_image_metadata returns a dict but doesn't document which keys are present. get_productivity_dashboard returns 'comprehensive' data but no schema for what that includes.
Default values for user_id appear hardcoded as 'demo-user' across most tools. This allows an agent to call tools without specifying which user's data to operate on, risking data leakage or incorrect associations. Defaults should be per-authenticated-user, not a shared fallback.
No visible tool-level error handling, recovery guidance, or actionable error messages. If delete_note fails (record locked, permission denied, not found), the tool provides no guidance on whether to retry, ask the user for clarification, or check preconditions.