Tools for agents: Task graph planner

Turn a dependency graph into ready tasks, parallel waves, and explicit blockers for collaborating agents.

Connect with MCP

{
  "mcpServers": {
    "super-agent-tools": {
      "url": "https://app.getsupers.com/sites/agent-task-graph/mcp"
    }
  }
}
Streamable HTTP · No API key · Stateless

Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.

Call plan_task_graph

Stateless planning. A dependency wave describes graph topology, not a claim or execution guarantee. Send updated statuses on the next call. Empty graphs are complete.

Input and output schemas
{
  "name": "plan_task_graph",
  "title": "Task graph planner",
  "description": "Validate a DAG and return ready work, parallel waves, blockers and dependency edges. No tasks are executed or stored.",
  "inputSchema": {
    "$defs": {
      "Task": {
        "properties": {
          "id": {
            "minLength": 1,
            "title": "Id",
            "type": "string"
          },
          "depends_on": {
            "items": {
              "type": "string"
            },
            "title": "Depends On",
            "type": "array"
          },
          "status": {
            "default": "pending",
            "enum": [
              "pending",
              "running",
              "completed",
              "failed"
            ],
            "title": "Status",
            "type": "string"
          }
        },
        "required": [
          "id"
        ],
        "title": "Task",
        "type": "object"
      }
    },
    "properties": {
      "tasks": {
        "items": {
          "$ref": "#/$defs/Task"
        },
        "title": "Tasks",
        "type": "array"
      }
    },
    "required": [
      "tasks"
    ],
    "title": "plan_task_graphArguments",
    "type": "object"
  },
  "outputSchema": {
    "additionalProperties": true,
    "title": "plan_task_graphDictOutput",
    "type": "object"
  },
  "icons": null,
  "annotations": {
    "title": null,
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  },
  "meta": null,
  "execution": null
}

Run the example to see the actual result.

HTTP alternative

POST https://app.getsupers.com/sites/agent-task-graph/call
Content-Type: application/json

{
  "tasks": [
    {
      "id": "research",
      "status": "completed"
    },
    {
      "id": "build",
      "depends_on": [
        "research"
      ]
    },
    {
      "id": "docs",
      "depends_on": [
        "research"
      ]
    },
    {
      "id": "verify",
      "depends_on": [
        "build",
        "docs"
      ]
    }
  ]
}

The HTTP and MCP interfaces execute the same implementation. Validation errors are returned explicitly. See the tool notes above for its supported inputs and behavior.

Dependency waves describe ready work without dispatching agents

Read the explanation

The saved example contains research, build, docs and verify. Research is already completed. Build and docs each depend on research, while verify depends on both build and docs. Four tasks create four dependency edges. At sixty pixels per count total tasks and edges each measure two hundred forty, while completed tasks one measures sixty. The planner contract validates a directed acyclic graph and returns ready work and blockers. It does not execute a task, store a claim or prove a collaborating agent is running. Because research is complete, build and docs can be ready together. Verify remains blocked until both finish. Two ready tasks and one blocked task form the three unfinished tasks. At eighty pixels per count these bars measure one hundred sixty, eighty and two hundred forty. Their parallel wave is a topology description rather than a staffing guarantee; one available worker would still need to process those ready tasks sequentially. A scheduler must separately enforce ownership, available capacity and actual completion evidence. After both build and docs are reported completed, verify is the one remaining task. Completed count becomes three and ready count one, totaling four. At seventy pixels per task these bars measure two hundred ten, seventy and two hundred eighty. An empty graph is complete by the saved contract. Callers must send updated statuses on each stateless call; a previous plan is not a durable live supervisor. The shared browser client is absent offline, so native JSON text and dimensions are preserved without claiming an actual HTTP or MCP plan result or new parallel worker.

Task Graph Planning and Topological Wave Partitioning

How does plan_task_graph partition tasks into waves and identify actionable work from DAG state?

The plan_task_graph tool validates a directed acyclic graph (DAG) and deterministically partitions tasks into dependency waves using Kahn's topological peeling algorithm. At each stage, tasks with all internal upstream dependencies resolved form an independent wave. In parallel, it evaluates the runtime status of each node: tasks marked pending with all incoming prerequisites completed become ready to execute, while unfulfilled dependencies populate blockers and upstream failures cascade down all dependent branches.

The planner is completely stateless: it neither executes tasks nor stores session state between invocations. Dependency waves represent graph topological depth, not runtime execution guarantees or duration-aware critical path schedules. Furthermore, failure propagation is strictly pessimistic; any failed upstream dependency flags all transitively reachable downstream tasks regardless of fallback logic.

Try a worked example

Click "Run tool" with the default four-task workflow. Because research is marked completed, the planner unblocks both downstream branches, placing build and docs in ready, while verify remains listed under blocked with pending prerequisites [build, docs]. Inspecting dependency_waves shows the static graph partitioned into three sequential levels: [research], [build, docs], and [verify].

Topological Wave Generation and Cycle Detection

The planner iteratively identifies all remaining nodes whose declared prerequisites contain no remaining unscheduled tasks. Each peeled set forms an execution wave sorted lexicographically by task identifier. If tasks remain but none have zero unresolved dependencies, the graph contains a directed cycle, and the tool raises a scheduling error.

Failure Cascading and Ready State Determination

A task is classified as ready only when its status is pending and every task listed in depends_on has status completed. If any prerequisite fails, that failure cascades transitively across all topological waves into failed_or_downstream, preventing downstream tasks from being dispatched without planner re-evaluation.