Tools for agents: Resource reservation conflict checker

Find overlapping reservations sharing resources, with exact overlap windows and peak resource concurrency.

Connect with MCP

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

Each reservation has a unique nonempty ID, integer start/end, and a list of distinct nonempty resource names. Coordinates may be integer timestamps or relative ticks, but all inputs must use the same unit and origin. Intervals are [start,end): touching endpoints do not conflict, and zero-length or reversed intervals fail. A conflict is one unordered reservation pair with a nonempty time intersection and at least one shared resource; multiple shared resources appear together in that pair. Pair order follows input order; shared resource names and resource summaries are sorted lexically. Peak windows are maximal contiguous intervals at that resource's highest concurrency, including adjacent windows whose reservation identities differ. Empty resource lists and empty reservation lists are valid. This assumes exclusive resources when declaring conflicts, does not infer capacities or time zones, and does not acquire locks, book resources, change schedules, or verify external availability. It analyzes only the submitted snapshot.

Input and output schemas

{
  "name": "find_resource_conflicts",
  "title": "Resource reservation conflict checker",
  "description": "Find every overlapping pair sharing resources and peak simultaneous reservations per resource. Endpoints are half-open integer coordinates.",
  "inputSchema": {
    "$defs": {
      "Reservation": {
        "additionalProperties": false,
        "properties": {
          "id": {
            "title": "Id",
            "type": "string"
          },
          "start": {
            "title": "Start",
            "type": "integer"
          },
          "end": {
            "title": "End",
            "type": "integer"
          },
          "resources": {
            "items": {
              "type": "string"
            },
            "title": "Resources",
            "type": "array"
          }
        },
        "required": [
          "id",
          "start",
          "end",
          "resources"
        ],
        "title": "Reservation",
        "type": "object"
      }
    },
    "properties": {
      "reservations": {
        "items": {
          "$ref": "#/$defs/Reservation"
        },
        "title": "Reservations",
        "type": "array"
      }
    },
    "required": [
      "reservations"
    ],
    "title": "find_resource_conflictsArguments",
    "type": "object"
  },
  "outputSchema": {
    "additionalProperties": true,
    "title": "find_resource_conflictsDictOutput",
    "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-resource-conflicts/call
Content-Type: application/json

{
  "reservations": [
    {
      "id": "render-a",
      "start": 0,
      "end": 10,
      "resources": [
        "gpu",
        "workspace"
      ]
    },
    {
      "id": "render-b",
      "start": 5,
      "end": 12,
      "resources": [
        "gpu"
      ]
    },
    {
      "id": "export",
      "start": 10,
      "end": 15,
      "resources": [
        "workspace"
      ]
    }
  ]
}

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.

Half-open reservations identify exact shared-resource conflicts

Your browser does not support video.

Read the explanation

The source example reserves render a from zero to ten on GPU and workspace, render b from five to twelve on GPU, and export from ten to fifteen on workspace. Render a and b overlap from five to ten and share GPU, so they form one conflict. Render b and export overlap in time but share no resource. Render a and export share workspace but only touch at ten, so they do not conflict. Intervals include start and exclude end. At time ten, render a has ended and export begins. Workspace therefore has concurrency one across zero through fifteen with changing reservation identity at ten. The contract merges adjacent peak windows even if their reservation identities change. Zero-length or reversed intervals are rejected rather than treated as reservations. GPU peak concurrency is two during five through ten. A conflict is one unordered reservation pair, even when several shared resources belong to that pair; names are grouped and sorted. Pair order follows input order. All times need the same unit and origin. Empty lists are allowed. The tool assumes exclusive resources but never books work, verifies external availability, acquires locks or changes schedules. These are source-contract examples; no backend call was made.

Resource reservation conflict checker

How does the conflict checker identify overlapping reservations and compute peak concurrency for shared resources?

The tool evaluates a snapshot of reservations defined across half-open integer intervals [start, end). For every pair of reservations sharing at least one resource name, it calculates the overlap interval [max(start_a, start_b), min(end_a, end_b)). A conflict is declared whenever this intersection is strictly positive in length. Concurrently, it sorts discrete start (+1) and end (-1) transition events across each resource to compute peak concurrency and identify maximal contiguous intervals at maximum demand.

The algorithm treats every named resource as strictly exclusive (capacity 1) for conflict reporting; multi-unit capacity pools or partial resource allocations are not supported. It operates entirely statestlessly on the provided payload and does not acquire distributed locks, manage time zones, or connect to external scheduling systems.

Try a worked example

Click 'Run tool' with the default three reservations. The service evaluates 'render-a' [0, 10) sharing 'gpu' and 'workspace', 'render-b' [5, 12) sharing 'gpu', and 'export' [10, 15) requesting 'workspace'. Because 'render-a' and 'render-b' both require 'gpu' over the intersection [5, 10), it flags exactly one conflicting pair with duration 5 and sets peak concurrency for 'gpu' to 2. At tick 10, 'render-a' ends as 'export' begins; because intervals are half-open, 'workspace' experiences zero conflict and peak concurrency remains 1.

Half-Open Interval Semantics and Pairwise Overlap

Intervals are interpreted as half-open sets [start, end), where the start coordinate is included and the end coordinate is excluded. Touching boundaries (where one interval ends at tick T and another begins at tick T) share no coordinate points in common and produce duration 0, avoiding spurious adjacency conflicts.

Pairwise conflicts are scanned exhaustively across unique reservation pairs. If any resource is shared and max(start_a, start_b) < min(end_a, end_b), an overlap record is formed containing the shared resources and the computed overlap span.

Sweep-Line Peak Concurrency and Maximal Windows

To determine resource concurrency, the implementation indexes boundary events for each resource: +1 at reservation start and -1 at reservation end. By iterating through ordered event boundaries, the running active count tracks simultaneous demand.