StudyMesh has 8 tools with basic naming and descriptions, but significant gaps in schema completeness, parameter documentation, and error handling. Tool names follow verb_noun convention (add_study_task, move_task, etc.), which is good. However, most tools lack detailed parameter descriptions, type constraints (enums for priority/status), and output schema documentation. Descriptions are present but generic (avg ~80 chars, below the 194-char baseline). No error handling guidance, no idempotent/destructive hints, and no recovery paths documented. The server is HTTP-based (good for transport), but tool definitions appear inferred from frontend JS rather than explicitly registered with full schemas in the backend.

• Add formal JSON Schema output definitions for each tool. E.g., add_study_task should document: {task_id: string, title: string, subject: string, priority: string, due: string, created_at: ISO8601}. This enables LLMs to chain calls (e.g., create task → move task using returned task_id).
• Convert priority and status parameters to enums in the schema. Replace 'priority: {type: string, description: "Priority level (low, med, high)"}' with 'priority: {type: string, enum: ["low", "med", "high"], description: "Priority level"}'. Remove example values from descriptions.
• Add error recovery guidance. When move_task returns 404, respond with: 'Task not found. Call list_tasks() to see available task IDs.' This guides the LLM to self-correct.
• Document what reschedule_tasks returns when task_ids is null. Does it return count of rescheduled tasks? A list of affected task IDs? This is critical for agents to verify the operation succeeded.
• Add tool annotations to the MCP tool registration. Mark track_progress with readOnlyHint=true, and destructive operations (move_task, reschedule_tasks) with destructiveHint=true. This helps agents reason about side effects.