add_commentLeave a plain comment on a task for your teammates. Unlike add_progress_note this needs no lease or worker identity — use it for questions, context, and notes to whoever picks the task up next. Comments appear in the task's activity timeline (get_task / get_task_activity) and in the Tango web UI.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Comment text. Mention teammates with @handle. | |
| task_id | Yes | Task id, or a pasted Tango task URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic safety signals (readOnlyHint=false, destructiveHint=false), and the description goes beyond them by clarifying that no lease or worker identity is required and that comments surface in the activity timeline and web UI. This adds useful behavioral context for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what it does, when to use it instead of the alternative, and where the result appears. The most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description covers purpose, usage distinction, and visibility of results. It is slightly above the minimum because it also addresses provenance of the comment, but a brief note on output/return behavior would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema with 100% coverage, so the description does not need to add much parameter detail. The mention of 'plain comment' and the alternative tool's context slightly reinforces the body semantics but adds no essential new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Leave a plain comment on a task') and immediately differentiates from add_progress_note. An agent can tell exactly what this tool does and how it differs from its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names the alternative (add_progress_note), states the distinguishing condition ('needs no lease or worker identity'), and gives the intended use cases ('questions, context, and notes'). This leaves no ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target a distinct resource and action, but several adjacent pairs are easy to confuse: add_comment vs add_progress_note, call_executor vs call_integration, log_client_decision vs update_client_context vs memory_save, and list_context_sources vs list_integrations. The descriptions do disambiguate them, but the boundaries are subtle enough that misselection is likely with 81 tools.
The overwhelming majority follow a clear verb_noun snake_case pattern (create_task, update_project, list_integrations, set_webhook), and get_/ list_/ create_/ update_ families are predictable. Minor deviations exist: memory_read/memory_save/memory_search invert to object_verb, and bare nouns like whoami, glossary, and security_posture break the pattern, but there is no chaotic casing or mixed conventions.
At 81 tools, this is far above the weight that is comfortable for an agent's tool-selection surface, especially since many tools belong to families that could be consolidated (webhooks, worker keys, project logs, context/memory). Although the domain is broad, the count will overwhelm agents and increase misrouting.
The surface is unusually comprehensive: tasks, projects, workers, leases, artifacts, comments, handoffs, webhooks, keys, context, memory, integrations, and support all have create/read/update/delete or equivalent lifecycle coverage. The gaps are minor, such as remove_dependency without a visible add_dependency and no artifact/comment deletion, but agents can work around them.