Loading ToolBench
MCP Server for MyTaskly with OAuth 2.1 authentication. Allows creation, consultation, and modification of tasks, categories, and notes for authenticated users.
MyTaskly MCP has 4 tools with reasonable naming and descriptions, but multiple schema and parameter quality gaps. Tool names follow verb-noun convention (get_tasks, get_categories, create_note, health_check). Descriptions are present and adequate (ranging 47-180 chars), but parameter schemas are incomplete. The create_note tool accepts an 'authorization' parameter explicitly, which is a security anti-pattern. Inputs lack type details for most parameters. No output schemas are documented anywhere in the provided code. Error handling is minimal, no indication of recovery guidance or categorization. Overall, this server is functional but falls short of production quality.
Create a new note for authenticated user.
Get all categories for authenticated user.
Get all tasks for authenticated user. Returns tasks formatted for React Native UI components with column definitions, formatted task data (dates, colors, emojis), summary statistics, voice summary for TTS, and UI hints for rendering.
Health check endpoint that returns status of both MCP server and FastAPI backend. No authentication required.
Credentials exposed as tool parameter: 'authorization' Bearer JWT token is passed as an explicit input parameter to get_tasks, get_categories, and create_note. This violates secret-injection pattern, credentials in tool parameters are logged, traced, and risk exposure.
No output schemas documented: The rubric requires documentation of return types for all tools. Code provides no evidence of structured output schemas, field definitions, or documentation of what get_tasks, get_categories, and create_note return. LLMs cannot plan downstream calls without knowing response structure.
Incomplete parameter schemas: Input schemas for create_note include position_x, position_y, color, and title with only type and description, but no min/max constraints, enum options, or format rules. E.g., position_x and position_y are strings (should be numbers?), color is hex but no pattern validation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Minimal error handling: No evidence in source code of error categorization (retryable vs user-fixable vs fatal), recovery guidance, or actionable error messages. If a task fetch fails or a note creation is denied, the agent receives no guidance on what to do next.
get_categories description too short: 'Get all categories for authenticated user.' is 47 characters, well below the recommended 50-200 character range. It lacks context about what categories represent, when to call it, or what structure they have.
No pagination or result limits documented: get_tasks returns 'all tasks' but the description gives no indication of pagination parameters (limit, offset, cursor), result limits, or total count. If a user has hundreds of tasks, the response may exceed context limits.