Skip to main content
Glama

Tango

by io.applayer

Complete a task and issue a receipt

complete_task

Step 5 of the Tango working agreement (finish). Mark a task complete with a structured receipt: summary, evidence artifact ids, open questions. Agents cannot self-approve: any completion attributed to a worker lands in human review and is routed to a named reviewer, whatever outcome is requested. Outcome 'done' self-approves for humans only. Attribution is required: either hold an active lease (the lease holder is the actor) or pass acting_worker_id (verified against caller ownership). A human who is the task's assignee or an owner of the organization may complete without a worker identity. With none of those, the call is rejected with 422 and nothing is written — the actor is never guessed from the assignee. Completion atomically releases the lease. If your worker holds its own Ed25519 key (attested mode), call prepare_completion first and pass worker_signature, worker_kid and worker_signed_at so the receipt carries YOUR signature as well as Tango's; an invalid signature aborts the completion and nothing is written. Delegated workers get a platform-produced signature automatically.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outcomeYes'review' hands to a human. 'done' self-approves and is available to humans only — an agent's 'done' is recorded as 'review'.
summaryYesWhat was done, in plain language.
task_idYesTask id, or a pasted Tango task URL.
worker_kidNoThe kid of the registered worker key that produced worker_signature.
open_questionsNoQuestions the next reviewer or agent should answer.
acting_worker_idNoOptional. Self-asserted worker completing this task. Ignored if a lease is active (lease holder wins). Verified against caller ownership; never inferred from the assignee.
transparency_seqNoThe transparency anchor seq you signed (from prepare_completion).
worker_signatureNoAttested mode only. Detached JWS ('header..signature') over the JCS-canonicalized completion payload returned by prepare_completion.
worker_signed_atNoThe exact `signed_at` value used inside the signed payload (ISO 8601).
decompose_outcomeNoFor tasks of type 'decompose' only. 'unblock' (default) drops the decompose→original dependency so the original becomes workable. 'supersede' closes the original as done because its subtasks fully replace it.
transparency_hashNoThe transparency anchor hash you signed (from prepare_completion).
evidence_artifact_idsNoArtifact ids that back the summary.

TDQS

A4.9/5.0
Behavior5/5

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

Discloses significant behavior beyond the annotations: agents cannot self-approve, completions attributed to workers land in human review, completion atomically releases the lease, invalid signatures abort with nothing written, and the actor is never guessed from the assignee. These are exactly the non-obvious behaviors an agent needs to know.

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

Conciseness5/5

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

The description is long but every sentence carries a distinct behavioral or routing rule. It is front-loaded with the step and purpose, then moves through approval, attribution, side effects, and signing modes without repetition or filler.

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

Completeness5/5

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

For a complex 12-parameter mutation tool with no output schema, the description covers the receipt contents, error paths, prerequisites, side effects, and mode differences. No critical operational gap remains for an agent deciding whether and how to invoke it.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds workflow-level meaning beyond the schema: it connects worker_signature, worker_kid, and worker_signed_at to prepare_completion, explains why they matter, and clarifies acting_worker_id ownership checking.

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

Purpose5/5

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

States a specific verb and resource: 'Mark a task complete with a structured receipt' and anchors it as 'Step 5 of the Tango working agreement (finish).' This clearly separates it from sibling tools like update_task or pause_task by defining completion as a finalizing action with a receipt.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and prerequisites: attested workers must call prepare_completion first, delegated workers get automatic signatures, humans may complete without worker identity, and calls without valid attribution are rejected with 422. It also clarifies that agent 'done' is recorded as 'review', preventing misuse.

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

All Tango toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness4/5

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.

Resources