Taskr MCP provides 22 tools across task management, devlogs, GitHub, skillflows, and Supabase integrations. All tools have descriptions and visible input schemas with types and descriptions for parameters. However, several critical issues limit overall quality: (1) Output schemas are not documented, the rubric requires documentation of what fields are returned so LLMs can plan downstream calls; (2) Error handling guidance is absent, tools provide no recovery hints, categorization of retryable vs fatal errors, or actionable error messages; (3) Parameter descriptions lack constraint details (e.g., taskr_list's 'limit' has no min/max bounds, status/priority values are vague); (4) Some parameter names are ambiguous (e.g., 'name_or_id' in skillflow_get forces LLMs to reason about which to pass); (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear READ/WRITE distinctions; (6) Generic descriptions for some tools (e.g., taskr_update says 'Update an existing task' but doesn't explain idempotency or side effects). Positive: tool naming is consistently verb-first and clear (taskr_create, taskr_assign, github_create_issue), all parameters have type annotations, descriptions exist for all parameters, and the modular plugin architecture is well-structured. The server is in Alpha (v0.1.0) and shows production intent but needs refinement in output documentation, error handling, and schema constraint details.

• Document output schemas for all 22 tools. Add a 'Returns:' section to each description or expose a structured output schema in the MCP tool definition. Include all fields an LLM might need (IDs, timestamps, URLs, references for chaining). Example: taskr_create should return {task_id: string, created_at: ISO8601, status: string, ...}.
• Add error handling guidance to WRITE tools (taskr_create, taskr_update, github_create_issue, supabase_deploy, supabase_sql_query, skillflow_execute, etc.). Specify: (a) What errors can occur (e.g., validation error, permission denied, timeout, conflict); (b) Whether each is retryable; (c) What the LLM should do (retry, ask user, fall back). Example: 'supabase_sql_query may fail with syntax errors (user-fixable), permission denied (fatal), or timeout (retryable after 5s).'
• Convert status and priority parameters to formal enums in the schema. Instead of describing 'Filter by status (open, in_progress, done, cancelled)' in text, define enum: ['open', 'in_progress', 'done', 'cancelled']. This is machine-parseable and prevents hallucinated values.
• Add numeric bounds to all 'limit' parameters. Specify minimum (e.g., 1) and maximum (e.g., 100). Use consistent defaults (suggest limit=20 or limit=50 for list operations). Update descriptions: 'Maximum results (1-100, default 20).'
• Split ambiguous parameters. Replace skillflow_get's 'name_or_id' with two separate parameters: 'skillflow_name' (string, kebab-case slug) and 'skillflow_id' (string, UUID), both optional. Document: 'Provide either name or id; id takes precedence if both supplied.'