Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server defines 9 tools with complete input schemas and consistent descriptions. Naming follows verb_noun convention (list_, create_, update_, delete_, complete_, search_). Descriptions are present but generic, averaging ~40-50 characters, below the 194-char baseline for production tools. All tools have properly typed schemas with required fields marked. However, output schemas are not documented anywhere, responses are returned as plain JSON text without structure hints for the LLM. Parameters lack format specifications (e.g., no guidance on ISO date format requirements, no minimum/maximum for lists). Error handling is not visible in the code sample, no recovery guides or actionable error messages. The server accepts credentials via environment variables (good pattern:secret-injection) but the TududuClient implementation is not shown, so we cannot verify actual secret handling.
Output schemas are not documented. Tools return JSON text without schema hints, forcing LLMs to parse unstructured responses. No guidance on expected fields, types, or pagination structure.
Descriptions are generic and under 100 characters. Examples: 'List all tasks from Tududi' (29 chars), 'Update an existing task' (23 chars). Baseline is 194 chars. Missing context on WHEN to use, WHAT is returned, and any dependencies.
No parameter format constraints or guidance. The 'dueDate' parameter says 'ISO format' but schema lacks pattern or minLength. The 'priority' enum is good, but search filters lack min/max for limit parameters (if supported).
Recommendations
Expand tool descriptions to 100-200 characters. Include WHEN to use the tool and WHAT it returns. Example: 'List all tasks from Tududi with optional filtering by project, area, or completion status. Returns a paginated array of task objects (ID, title, status, priority, due date). Call this first to discover task IDs before updating or deleting.', this is ~180 chars and actionable.
Add output schema documentation. After the tool definitions, add comments or a response schema block describing the structure: 'Returns: {tasks: [{id, title, description, completed, priority, dueDate, projectId}], total, nextCursor}'. This guides LLM parsing.
Add pagination parameters to list and search tools. Add 'limit' (default 20, max 100) and 'offset' or 'cursor' parameters to tududi_list_tasks, tududi_list_projects, tududi_list_areas, and tududi_search_tasks. Update descriptions to note 'Results are limited to 20 per page; use offset/limit for pagination.'
Add format constraints to parameter descriptions. For 'dueDate', clarify: 'ISO 8601 date string (YYYY-MM-DD) or ISO datetime (YYYY-MM-DDTHH:mm:ssZ)'. For 'priority', the enum is correct; keep it.
Document parameter relationships. In tududi_create_task, clarify: 'Either projectId or areaId may be specified; both are optional. If both are provided, the task is created in the specified project within the area.'
Add error handling examples. In the CallToolRequestSchema handler, catch specific errors and return actionable messages. Example: 'Task not found. Available tasks: [list IDs]. Call tududi_list_tasks() to see all tasks.'
List and search tools do not declare pagination. No mention of limit, offset, page_size, or result count. If an agent calls list_tasks and gets 1000 items, it will blow the context window. Pagination parameters are missing.
Error handling is not visible in the code. No recovery guides, actionable error messages, or error categorization (retryable vs fatal). The CallToolRequestSchema handler has a try-catch that likely throws raw exceptions.
No confirmation or dry-run pattern for destructive operations. tududi_delete_task can permanently remove a task with no warning or undo. Agents make mistakes, a confirmation step would prevent data loss.
Parameter descriptions lack dependency hints. For example, tududi_update_task accepts 'id' but does not explain how to discover task IDs (use list_tasks first). tududi_create_task mentions 'projectId' and 'areaId' but does not explain when both are needed or if one is optional.
Implement a confirmation pattern for delete_task. For example, return {action: 'confirm_delete', taskId: '...', taskTitle: '...'} and require a separate confirm_delete_task(taskId, confirmationToken) call to proceed. Or add a dry_run parameter.
Add dependency hints to parameter descriptions. For tududi_update_task: 'Task ID can be obtained from tududi_list_tasks() or tududi_search_tasks().'
Specify result limits in descriptions. 'Returns a list of up to 20 tasks. For larger result sets, use pagination parameters (offset, limit) or refine your search query.'
Document idempotency. Clarify which tools are safe to retry (all of them, ideally). If update_task is idempotent by design, state: 'Idempotent: calling this multiple times with the same parameters produces the same result.'