Descriptions too brief and lack WHEN/WHY context. 8 tools have descriptions under 50 characters, violating the 50-200 char baseline for LLM-optimized tools. Examples: 'Get a project status update' (31 chars), 'Get detailed information about a specific project' (48 chars).

Output schemas completely undocumented. Tools do not declare what fields they return, forcing LLMs to infer structure or guess what IDs/references to use for chaining. Critical for downstream tool calls.

No error handling guidance. Tools do not document what errors are possible, what they mean, or how to recover. Example: asana_delete_tag does not explain 'tag not found' vs 'permission denied' vs 'in-use tag cannot be deleted'.

Generic 'opt_fields' parameter exposed in most tools without clear guidance. LLMs cannot know which fields are available or important to request. This is an API implementation detail that should be abstracted or removed, forcing agents to guess or call redundantly.

Destructive tools (delete_tag, delete_project_status) have no confirmation or dry-run support. Agents can trigger irreversible operations without safeguards.

Inconsistent parameter naming: some use 'gid', others use 'id', and some use '_id' suffix. Example: asana_get_project uses 'project_id' while asana_create_project_status expects 'project_gid'. LLMs may pass wrong field types.

Enum constraints missing on color parameters. asana_create_project_status declares color enum as [green, yellow, red] but asana_create_project color accepts 16 possible values described in text. No enum constraint lets LLMs hallucinate invalid colors.

asana_create_task_story requires one of 'text' or 'html_text' but schema doesn't enforce mutual exclusivity or one-of logic. LLMs may pass neither or both, causing failures.

asana_set_parent_for_task has deeply nested parameters (data object with nested properties) that are awkward for LLM invocation. insert_after/insert_before are mutually exclusive but not marked as such.