MCP server for intelligent task planning and organization. Reads TODO files, prioritizes tasks, and generates weekly plans.
This server has 3 clearly defined tools with registered schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools are read-only operations on task data. Tool naming follows verb_noun conventions (read_, prioritize_, generate_). Descriptions exist but are terse (30 - 60 chars), below the 50 - 200 char production baseline. Input schemas are visible in server.py and tools.py, but lack detailed parameter descriptions, only basic type info. Output schemas are inferred from Pydantic models (ReadTodoFileOutput, PrioritizeTasksOutput, GenerateWeeklyPlanOutput) but not documented in tool docstrings. Error handling is minimal: FileNotFoundError for missing files, but no recovery guidance or structured error responses. The server is STDIO-only transport, which is a hard cap at 50/100 regardless of definition quality, STDIO cannot work with hosted/remote MCP clients.
Distribuye las tareas priorizadas en un plan semanal balanceado.
Clasifica tareas por prioridad alta, media o baja con una justificación simple.
Lee un archivo TODO en Markdown y devuelve una lista estructurada de tareas.
Descriptions are below production baseline (50 - 200 chars). All three tools have descriptions under 80 chars; the scoring baseline is 194 chars average, p10=34, p90=392. Terse descriptions reduce LLM ability to disambiguate when to select each tool.
Output schemas are not documented in tool docstrings. All three tools return structured Pydantic models (ReadTodoFileOutput, PrioritizeTasksOutput, GenerateWeeklyPlanOutput), but the MCP tool descriptions do not state what fields and types are in the response. LLMs cannot plan downstream calls without knowing the output structure.
Parameter descriptions lack actionable constraint details. For 'prioritize_tasks', the 'tasks' parameter has only 'Lista de tareas a priorizar', no mention of max task length, format, or examples. For 'generate_weekly_plan', the 'prioritized_tasks' parameter does not state the required schema or that priority must be one of [high|medium|low]. LLMs infer constraints from descriptions; vague descriptions invite invalid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Minimal error handling and no recovery guidance. 'read_todo_file' raises FileNotFoundError with a generic message; no suggestion for what to do next (e.g., 'List available task files'). Error responses must guide the LLM toward recovery, not just report failure.
STDIO-only transport. Server uses FastMCP with STDIO protocol (stdio_client in tool_client.py). STDIO servers are not remotely accessible and cannot work with hosted MCP clients. This is a hard architectural limitation that caps protocol readiness at 50/100.
Enum constraints not explicitly stated in parameter descriptions. The 'priority' field in 'generate_weekly_plan' accepts high|medium|low (enforced in Pydantic), but this constraint is not mentioned in the parameter description. The description should state: 'Priority level (one of: high, medium, low)' to guide the LLM.
Undocumented task distribution logic and limits. 'generate_weekly_plan' splits tasks across a fixed 7-day schedule (monday - sunday) with 2 days for high priority, 3 for medium, 2 for low. This distribution strategy and any per-day task limits are not documented in the tool description. If an agent passes 100 high-priority tasks, the tool silently cycles through the 2 high-priority days without warning.