If you are building an MCP server for task tracking, you eventually hit the same wall: the work outlives the connection. As of June 2026, that is exactly the gap MCP Tasks is trying to close. The important part is not that it exists — it is how far the protocol has actually stabilized, what still looks experimental, and where application-layer task boards already solved the same shape in a different way.

This post is a skeptical read for developers and technical architects. We will walk through the current MCP Tasks semantics, look at the state machine, compare the extension to A2A, and end with a minimal application-layer example of durable, agent-readable task state. Agiflow appears only as one concrete example of a board that exposes scoped task state to agents, not as a recommendation or a proof of spec maturity.

Why this exists at all

The core problem is simple: long-running work does not fit cleanly into a request/response cycle. If the model needs to wait for a batch job, a human approval, or a slow external API, blocking a connection is fragile and hard to resume.

The current MCP roadmap makes that explicit. The 2026 MCP roadmap (captured 2026-06-02) still treats task lifecycle edge cases as active protocol work, and the Tasks overview (captured 2026-06-02) describes a durable handle, not a streaming socket replacement.

That distinction matters. A task ID is a state handle. It is not a chat transcript. It is not a job queue. It is not a promise that every client and server will agree on the same retry behavior next quarter.

The shape of MCP Tasks

The protocol model is a durable task with a small state machine. The useful bit for builders is that the shape is explicit:

MCP Tasks state machine: working and input_required are non-terminal; completed, failed, and cancelled are terminal. Source: MCP Tasks extension overview (captured 2026-06-02).

The easiest way to see the negotiation is to look at the client and server capabilities side by side.

{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "extensions": {
        "io.modelcontextprotocol/tasks": {}
      }
    }
  }
}

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/tasks": {}
    }
  }
}

If both sides opt in, the server can return a CreateTaskResult instead of a synchronous result.

{
  "resultType": "task",
  "task": {
    "taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2",
    "status": "working",
    "ttlMs": 600000,
    "pollIntervalMs": 2000
  }
}

The point of the ttlMs and pollIntervalMs fields is not cosmetic. They tell the client how long the task can reasonably be resumed and how often to ask for an update.

Polling, completion, and input_required

Once a task exists, the client follows a straightforward loop: poll until terminal, or respond if the server pauses for input.

{
  "taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2"
}

{
  "taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2",
  "status": "completed",
  "result": {
    "summary": "Build finished successfully.",
    "artifacts": [
      "dist/app.js",
      "dist/app.js.map"
    ]
  }
}

If the work needs a decision, the protocol explicitly stops pretending it can continue alone.

{
  "taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2",
  "status": "input_required",
  "inputRequests": {
    "approve_release": {
      "type": "confirmation",
      "message": "Approve deployment to staging?"
    }
  }
}

{
  "taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2",
  "inputResponses": {
    "approve_release": {
      "confirmed": true
    }
  }
}

That is the most useful mental model here: task state is not an implementation detail. It is a protocol surface for deferred work.

The experimental repository reinforces the caution. The experimental Tasks spec repo (captured 2026-06-02) labels the extension experimental and warns that it may change or disappear. That does not make it unusable. It does mean you should treat it like an evolving contract.

What is stable for MCP task tracking in production

My read is conservative:

• Safe to build on: the existence of a durable task handle, explicit task states, polling, and cooperative cancellation.
• Use with caution: exact retry behavior, retention/expiry policy, and any client-specific push notification behavior.
• Do not over-interpret: the fact that a task exists does not mean every agent workflow should become a task.

The roadmap backs that up. In the 2026 MCP roadmap (captured 2026-06-02), retry semantics and result-retention policy are still called out as open gaps. That is a clue that the shape is real, but the surrounding policy is still settling.

There is also market signal, but it is still only market signal. SiliconANGLE's February 12, 2026 report on Manufact (captured 2026-06-02) shows money flowing into MCP infrastructure. That says the category is getting real attention. It does not prove the protocol has finished evolving.

MCP Tasks is not the only answer

If your use case is agent-to-agent collaboration rather than deferred execution, you should also look at A2A. The A2A specification (captured 2026-06-02) focuses on inter-agent communication, capability discovery, and collaborative tasks with its own task lifecycle and message model.

That makes the comparison easier:

In other words, use the simplest layer that matches the problem. MCP Tasks is a good fit when the work is still fundamentally one request that needs to finish later. A2A is a better fit when the work is really a conversation between agents.

A minimal application-layer analogue

This is the part that often gets conflated with the protocol extension. A board can expose the same shape without implementing MCP Tasks itself: stable ID, readable status, and a write path that updates state as work progresses.

Two independent primitives that independently converge on the same structural shape: stable durable ID, explicit status state machine, and pollable/readable state.

That is close to what Agiflow's connection docs show at the application layer: a scoped task endpoint that lets an assistant work against durable board state. The important distinction is still the same one from above. That is an application-level model, not proof that the product implements the MCP Tasks extension.

type TaskStatus = "working" | "input_required" | "completed" | "failed" | "cancelled";

type TaskRecord = {
  taskId: string;
  title: string;
  status: TaskStatus;
  updatedAt: string;
  notes?: string;
};

const tasks = new Map<string, TaskRecord>([
  [
    "task_123",
    {
      taskId: "task_123",
      title: "Review deployment checklist",
      status: "working",
      updatedAt: new Date().toISOString(),
    },
  ],
]);

export function readTaskState(taskId: string): TaskRecord | undefined {
  return tasks.get(taskId);
}

export function writeTaskState(
  taskId: string,
  patch: Partial<Pick<TaskRecord, "status" | "notes">>,
): TaskRecord {
  const current = tasks.get(taskId);

  if (!current) {
    throw new Error(`Unknown task: ${taskId}`);
  }

  const next: TaskRecord = {
    ...current,
    ...patch,
    updatedAt: new Date().toISOString(),
  };

  tasks.set(taskId, next);
  return next;
}

const before = readTaskState("task_123");

if (before?.status === "working") {
  writeTaskState("task_123", {
    status: "input_required",
    notes: "Need approval for the release window.",
  });
}

This is the same shape MCP Tasks is formalizing, minus the protocol mechanics. You can swap the in-memory Map for a database row, a Durable Object, a project board record, or an external job handle. The pattern stays the same.

What I would do in practice

My rule of thumb is boring on purpose:

• Use core MCP for synchronous tool calls.
• Use MCP Tasks when the work is truly deferred and the client can resume later.
• Keep the state machine simple and terminal-state driven.
• Treat push notifications as an optimization, not a requirement.
• Reach for A2A when the problem is really agent coordination, not deferred execution.

That gets you most of the value without pretending the extension is more mature than it is.

Wrapping up

The useful headline is not "MCP Tasks is done." The useful headline is that MCP server task tracking now has a credible protocol shape: durable, resumable, long-running work that survives disconnects. That is a real step forward, but it is still an evolving surface area, so the safest implementation stance is conservative.

If you want to see how a real product scopes assistants to board state and task context, start with Agiflow's connection docs. It is a good application-layer contrast to the protocol story here, and it makes the boundary between "board state" and "protocol task" much easier to see.