Server exposes 8 tools with basic schemas and Portuguese descriptions. Tool names follow verb_noun pattern (devs_loop_*) but lack clarity on action semantics. Schemas are present but parameter descriptions are missing entirely, only type constraints visible. Output structure uses createResponse() helper but no documented return schema. Error handling exists (withToolCapture) but provides minimal recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Composition is reasonable (single responsibility per tool), but parameter naming could be more explicit (e.g., 'listId' vs 'list_id'). Descriptions are adequate (50-150 chars) but lack WHEN/WHY context for LLM selection.

• Add parameter descriptions to all Zod schemas. For each parameter, explain what it controls, valid range/format, and dependencies. Example: 'project: string, The project key (2-10 chars, must exist in config). Call devs_loop_projects() first to list available projects.'
• Document output schemas formally. Define the structuredContent object structure for each tool (e.g., devs_loop_create_task returns {taskId, taskUrl, checklist, timer}). Include field types and descriptions.
• Enhance error messages with recovery guidance. Instead of 'Projeto não encontrado', return 'Project "xyz" not found. Available projects: [list]. Call devs_loop_projects() to see all options.'
• Add tool annotations via MCP SDK. Mark WRITE tools with destructiveHint: true and idempotentHint: false (or true if safe to retry). Mark READ tools with readOnlyHint: true.
• Standardize parameter naming to snake_case (list_id, start_timer, task_id) for consistency with MCP conventions and to reduce LLM confusion across tools.