Asana MCP has well-structured tool definitions with clear naming (verb_noun pattern) and reasonable descriptions (avg 150 chars). All 6 tools have input schemas with type declarations and required fields. However, parameter descriptions are sparse or missing context (e.g., 'Workspace GID (auto-resolved if omitted)' lacks explanation of what auto-resolution means). Output schemas are not documented, callers cannot predict response structure. Error handling is minimal (generic 'Asana API error' messages). No pagination guidance despite list tools accepting limits. Missing tool annotations (readOnlyHint, destructiveHint). The server lacks idempotency guarantees and does not document which tools are safe to retry.

• Document output schemas for all tools. Add a 'Returns' section to each tool description specifying field names, types, and meanings. E.g., 'Returns {tasks: [{gid: string, name: string, completed: boolean, assignee: {name: string}, due_on: string, permalink_url: string}]}'.
• Enhance parameter descriptions with format and validation rules. Replace 'Workspace GID (auto-resolved if omitted)' with 'Workspace GID (string, auto-resolved to user's default workspace if omitted; required for multi-workspace accounts)'. Add enum constraints for status-like fields.
• Implement error classification and recovery guidance. Catch Asana API errors and return structured responses: {error: 'not_found', message: 'Task not found', recovery: 'Verify task GID with asana_search_tasks()'}. Distinguish retryable (429, 5xx) from user-fixable (400, 404) errors.
• Add tool annotations. Mark asana_create_task with destructiveHint: true. Mark read-only tools (list_*, get_*, search_*) with readOnlyHint: true. Mark idempotent tools (get_task, list_*) with idempotentHint: true.
• Document pagination strategy. Clarify whether list tools support offset/limit or cursor-based pagination. Return total_count or next_cursor in responses. Add example: 'To fetch next 20 tasks, call asana_list_tasks with limit=20 and offset=20'.