Tools for agents: Critical-path timing analysis

Compute workflow timing, total slack and critical dependency edges from exact task durations.

Connect with MCP

{
  "mcpServers": {
    "super-agent-tools": {
      "url": "https://app.getsupers.com/sites/agent-critical-path/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 `analyze_critical_path`

Planning only: does not run tasks, reserve workers or persist state. All tasks are unstarted at time zero. Dependencies are finish-to-start with no lag. Assume unlimited parallel resources, no calendars, release dates or deadlines. Use one consistent duration unit; all timing values are exact fraction strings in that unit. Integers or quoted decimal/fraction strings are accepted; JSON floats and booleans are rejected. Zero-duration milestones are allowed. Each terminal task must finish by the overall earliest project completion. Total slack is how far that task can shift while preserving that completion under these assumptions. Critical tasks have zero slack; critical_edges includes only tight dependencies between them, representing all critical routes without enumerating exponentially many paths. Disconnected components are included. Duplicate IDs, duplicate/unknown dependencies, cycles and negative durations fail explicitly. This is not a resource-constrained schedule or a promise of real completion time.

Input and output schemas

{
  "name": "analyze_critical_path",
  "title": "Critical-path timing analysis",
  "description": "Compute earliest/latest start/finish and total slack for a finish-to-start DAG using exact durations. Assume unlimited resources, all tasks unstarted, no lags or calendars.",
  "inputSchema": {
    "$defs": {
      "TimedTask": {
        "properties": {
          "id": {
            "minLength": 1,
            "title": "Id",
            "type": "string"
          },
          "duration": {
            "anyOf": [
              {
                "type": "integer"
              },
              {
                "type": "string"
              }
            ],
            "title": "Duration"
          },
          "depends_on": {
            "items": {
              "type": "string"
            },
            "title": "Depends On",
            "type": "array"
          }
        },
        "required": [
          "id",
          "duration"
        ],
        "title": "TimedTask",
        "type": "object"
      }
    },
    "properties": {
      "tasks": {
        "items": {
          "$ref": "#/$defs/TimedTask"
        },
        "title": "Tasks",
        "type": "array"
      }
    },
    "required": [
      "tasks"
    ],
    "title": "analyze_critical_pathArguments",
    "type": "object"
  },
  "outputSchema": {
    "additionalProperties": true,
    "title": "analyze_critical_pathDictOutput",
    "type": "object"
  },
  "icons": null,
  "annotations": {
    "title": null,
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  },
  "meta": null,
  "execution": null
}

Structured result

Run the example to see the actual result.

HTTP alternative

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

{
  "tasks": [
    {
      "id": "research",
      "duration": 2
    },
    {
      "id": "build",
      "duration": 5,
      "depends_on": [
        "research"
      ]
    },
    {
      "id": "docs",
      "duration": 3,
      "depends_on": [
        "research"
      ]
    },
    {
      "id": "verify",
      "duration": 1,
      "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.

Exact timing under unlimited parallel resources

Your browser does not support video.

Read the explanation

The shown example has research duration two. Build duration five and docs duration three both depend on research. Their earliest finishes are seven and five. Verification duration one waits for both, starting at seven and finishing at eight. Bars use fifty five pixels per duration unit to show branch finish times. This derivation follows the page contract of unlimited parallel resources, not a real worker reservation. The project earliest completion is eight. Verification must begin at seven, so documentation of duration three can start as late as four. Its earliest start was two, leaving two units of total slack. Build must start at two and finish seven, so it has zero slack. Bars compare earliest and latest starts in one time unit. Resource limits, calendars and release dates are outside this planner contract. The critical route research, build, verification sums to eight, while the documentation route sums to six. Exact fraction strings avoid binary decimal timing in the described implementation. But this saved HTML delegates execution to a shared service and lacks that shared application script locally. Offline checks can inspect the argument form and layout; they cannot prove the actual HTTP or MCP result. We do not call or alter those backend interfaces.

Understanding Critical-Path Timing Analysis

How does critical-path analysis determine project duration, total slack, and critical dependency edges?

Critical-path timing analysis evaluates a directed acyclic graph (DAG) of project tasks using forward and backward mathematical passes. The forward pass establishes earliest possible start and completion timestamps by calculating cumulative dependencies, while the backward pass computes latest permissible start and finish times to maintain the earliest overall project completion. Tasks whose earliest and latest schedules coincide have zero total slack; these tasks and their tight dependencies form the critical path that governs overall project duration.

This analytical implementation assumes infinite concurrent worker capacity, finish-to-start relationships without lag, deterministic rational durations, and the absence of calendars, release dates, or external milestones. It does not solve resource-constrained project scheduling problems (RCPSP) or model stochastic PERT duration distributions.

Try a worked example

Submitting the default task set ('research' lasting 2, 'build' lasting 5, 'docs' lasting 3, and 'verify' lasting 1) computes a minimum project completion time of 8. The task 'docs' has an earliest finish of 2 + 3 = 5 and a latest finish of 8 - 1 = 7, giving it a total slack of 2 units (latest start 4 minus earliest start 2). Tasks 'research', 'build', and 'verify' have zero slack, identifying them as critical tasks connected by tight critical edges ('research' to 'build' and 'build' to 'verify').

Forward and Backward Schedule Passes

The critical path method processes tasks ordered by topological dependency waves. The forward pass computes for each task the earliest start as the maximum earliest finish of its predecessors (defaulting to 0 for unconstrained root tasks) and sets the earliest finish as earliest start plus duration. The project makespan is the maximum earliest finish across all tasks.

In the backward pass, each task's latest allowable finish is computed as the minimum latest start among its direct successors (defaulting to overall project makespan for terminal tasks). The latest start equals latest finish minus task duration.

Total Slack and Critical Path Identification

Total slack represents the duration a task can slip without delaying overall project makespan, calculated as latest start minus earliest start (or latest finish minus earliest finish). Tasks with zero total slack are designated critical.