Server has 6 read-only tools with basic Zod schemas and minimal descriptions. All tools follow verb_noun naming (get_*), but descriptions are generic (10-50 chars, well below the 194-char baseline). No parameter descriptions beyond type hints. Output schemas are undocumented, responses are raw API data without field documentation. No error handling guidance, no pagination metadata in responses, and no indication of what fields downstream tools should expect. Schemas are present but sparse; parameters lack actionable constraints or format guidance.

• Expand tool descriptions to 100-200 chars. Example: 'asana_get_task' → 'Retrieve a single task from Asana by task ID. Returns task details including name, description, assignee, due date, and custom fields. Use this to fetch full task context before updating or commenting.'
• Add parameter descriptions in Zod schemas or via JSDoc comments. Example: 'offset: z.string().optional().describe("Pagination offset token from previous response. Omit to start from the first result.")' and 'limit: z.number().optional().describe("Max results per page (1-100, default 10). Asana may return fewer if fewer exist.")'
• Document output schemas explicitly. Add a comment block above each tool showing expected response fields: task_id, name, assignee_id, due_date, etc. Include which fields are required for downstream tool calls.
• Add error handling with recovery hints. Wrap API calls in try-catch and return structured errors: '{"error": "Task not found", "task_id": "<input>", "recovery": "Verify the task ID is correct. Use asana_get_tasks_by_project to search by project."}'
• Document pagination behavior. Add to tool descriptions: 'Supports pagination via offset and limit. If next_page is present in response, call again with offset=<next_page> to fetch more results.' Return total_count if available.