Tasks Tools

Why this matters

Autonomous systems hit real-world latency: long plans, multi-step workflows, slow upstream APIs, and user approvals. Instead of forcing the caller to wait for the full job inline, DataGrout can return a durable task_ref and continue the work in the background. The Tasks suite is the control plane for that handoff.

Five tools

• ✓tasks.status — Poll a task by task_ref to see whether it is working, completed, failed, or cancelled
• ✓tasks.wait — Reattach for a bounded wait window and either receive the terminal result or a fresh in-progress snapshot
• ✓tasks.list — Review recent background work for the current server, including task state, timestamps, and poll interval
• ✓tasks.result — Retrieve the completed result payload once a task reaches a terminal state
• ✓tasks.cancel — Cancel work that is no longer relevant and mark the task terminal

Automatic MCP timeout handoff

The MCP gateway promotes work to a background task shortly before the protocol wall clock expires, then returns a response that includes the task_ref. Agents can keep moving, periodically reattach with tasks.wait, poll with tasks.status, and only fetch the full payload with tasks.result when the work is done.

Example: poll and retrieve

// Check whether an MCP-promoted background job is still running
{ "name": "data-grout@1/tasks.status@1",
  "arguments": { "task_ref": "task_abc123" }
}

// Reattach briefly without committing to pure polling
{ "name": "data-grout@1/tasks.wait@1",
  "arguments": { "task_ref": "task_abc123", "wait_ms": 25000 }
}

// Fetch the completed result once the task reaches a terminal state
{ "name": "data-grout@1/tasks.result@1",
  "arguments": { "task_ref": "task_abc123" }
}

This pattern is especially useful for multi-step workflows, long-running discovery plans, and tool calls that may need to wait on upstream systems or user approvals.