Tango

Update a task

update_task

Edit an existing Tango task in place. If client_id changes, task.agency_id is re-derived from the new client (client is authoritative). To reassign, use handoff_task. Cross-agency edits require allow_cross_agency: true; the change is audit-logged. API reference: https://tango.applayer.io/docs/api/tools/update_task

Input Schema

TableJSON Schema

Name	Required	Description
`goal`	No
`role`	No
`type`	No
`title`	No
`inputs`	No	Additional governed inputs to pin to this task. Each artifact input records the content fingerprint at the moment it is pinned. Adds to the existing inputs; it does not replace them.
`status`	No	Move the task. Use `blocked` for work parked on a dependency, `cancelled` for work called off, and `archived` to shelve a task nobody will ever pick up. Agents cannot set `done`/`approved` — hand back for review instead.
`project`	No	Move the task to this project (name or @handle). Must belong to the task's client.
`sources`	No
`task_id`	Yes	Task id, or a pasted Tango task URL.
`deadline`	No
`authority`	No	Replace what the worker may do unattended. Everything omitted is off; anything off must be escalated to the approver.
`client_id`	No
`parent_id`	No
`depends_on`	No	Replace the full set of prerequisite task ids. Pass [] to clear.
`project_id`	No	Move the task to this project id.
`constraints`	No
`description`	No
`status_reason`	No	Required when setting `blocked` or `cancelled`: a short human-readable why.
`evidence_required`	No	Set the evidence this task must carry before complete_task is accepted. Replaces any existing policy; pass [] to fall back to the organization default, or null to clear the override.
`allow_cross_agency`	No
`definition_of_done`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 22, 2026

addedInput schema / properties / authority

Added value: +{
+  "description": "Replace what the worker may do unattended. Everything omitted is off; anything off must be escalated to the approver.",
+  "properties": {
+    "contact_client": {
+      "type": "boolean"
+    },
+    "deploy": {
+      "type": "boolean"
+    },
+    "merge": {
+      "type": "boolean"
+    },
+    "note": {
+      "maxLength": 500,
+      "type": "string"
+    },
+    "publish": {
+      "type": "boolean"
+    },
+    "send": {
+      "type": "boolean"
+    },
+    "spend": {
+      "type": "boolean"
+    },
+    "spend_cap_usd": {
+      "exclusiveMinimum": 0,
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / inputs

Added value: +{
+  "description": "Additional governed inputs to pin to this task. Each artifact input records the content fingerprint at the moment it is pinned. Adds to the existing inputs; it does not replace them.",
+  "items": {
+    "properties": {
+      "artifact_id": {
+        "format": "uuid",
+        "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+        "type": "string"
+      },
+      "external_url": {
+        "format": "uri",
+        "type": "string"
+      },
+      "label": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "note": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "label"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedAug 29, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and destructiveHint=false, so the bar is low, and the description clears it by disclosing that changing client_id re-derives agency_id (client authoritative), that cross-agency edits need a flag, and that the change is audit-logged. These are non-obvious side-effects an agent would not infer from the schema. It doesn't describe what happens to omitted fields or whether the edit is reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly written sentences lead with the core purpose, then append the two highest-value caveats (alternative tool, cross-agency flag), followed by a doc link. Every sentence earns its place, though the raw API URL adds length without much semantic content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 21 parameters including nested objects, the description is reasonably complete: it covers purpose, the key alternative, cross-agency semantics, and audit logging, and defers the rest to inline schema descriptions. It could say more about what 'in place' means for omitted vs. replaced fields on a tool this large.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43% across 21 parameters, so the description should compensate more than it does. It adds meaningful semantics for client_id (agency_id re-derivation) and allow_cross_agency, but leaves many fields (goal, role, type, sources, constraints, definition_of_done) with no explanation in either place. It adds partial value beyond the schema, consistent with a 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Edit an existing Tango task in place', which clearly identifies the operation. It also distinguishes the tool from handoff_task for the reassignment case, so an agent can route correctly. It stops short of 5 because it doesn't differentiate from bulk_update_tasks or other update_* siblings, and 'in place' is a touch vague about whether fields are replaced or merged.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names an explicit alternative ('To reassign, use handoff_task') and a concrete precondition ('Cross-agency edits require allow_cross_agency: true'), which is real routing guidance. It lacks a general when-not statement relative to create_task, bulk_update_tasks, or complete_task, so it falls short of exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tango tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?