Skip to main content
Glama

concurrent_delay_matrix

Build the per-window x per-party concurrent-delay attribution matrix from a chronological list of XER snapshots.

        Implements the per-window concurrency view per AACE RP 29R-03
        §3.3.I (apportionment) and §4.2 (concurrency). Where
        ``forensic_windows_analysis`` answers "how many days does each
        party own across the whole project?", this tool answers "how did
        each window distribute its shift across the parties?" — useful
        when defending or attacking concurrency findings on a
        window-by-window basis.

        CPP conservation check, per the AACE 29R-03 §3.3.E.13
        requirement that the summed per-period net impacts equal the
        difference between the first schedule update and the last
        schedule update used in the evaluation: the sum of per-party
        column totals equals the sum of per-window completion shifts
        within ±1 day of rounding. The column-total definition is this
        tool's own bookkeeping, not an AACE rule. The ``conservation_check`` field on
        the response reflects this; ``conservation_diff_days`` carries
        the exact gap.

        IMPORTANT — conservation is NOT attribution. ``conservation_check``
        can be True (the columns sum to the grand total) even when 100% of
        the shift lands in the Unattributed column, i.e. no party owns any
        of the drift. Read ``unattributed_share_pct`` and
        ``high_unattributed_share_warning`` to know whether a meaningful
        apportionment actually occurred. A fully-unattributed matrix
        conserves perfectly but attributes nothing — never present its
        green conservation check as a validated apportionment.

        Use this tool when you only need the matrix view; use
        ``forensic_windows_analysis`` for the full claim.

        Args:
            schedules: chronologically ordered list of dicts — the SAME
                shape ``forensic_windows_analysis`` accepts. Each dict
                carries ``label`` (optional) and EXACTLY ONE of
                ``xer_content`` (full XER text, hosted/remote use) or
                ``xer_path`` (server-side path, local use). This is the
                preferred input for hosted/remote clients.
            xer_paths: legacy chronologically ordered list of server-side
                XER file paths (local-server use).
            xer_contents: legacy chronologically ordered list of XER text
                contents. Each element is the full text of one XER.
            Supply EXACTLY ONE of schedules / xer_paths / xer_contents
            (lists must have at least 2 entries either way).

        Returns:
            {
              "parties": ["Owner", "Contractor", "Concurrent",
                          "Force Majeure", "Unattributed"],
              # Unit for every shift_* field and the grand totals. Always
              # "working_days" — the matrix measures the completion shift
              # in working days (Dana default). The *_calendar_days twins
              # express the SAME shift in calendar days so an unlabeled
              # "11" can never be mistaken for the 15-calendar-day value.
              "shift_unit": "working_days",
              "rows": [{ "window_label", "period_start", "period_end",
                         # shift_days == shift_workdays (working days,
                         # legacy alias). shift_calendar_days is the same
                         # shift in calendar days; shift_basis names the
                         # finish driver the shift was measured on.
                         "shift_days", "shift_unit", "shift_workdays",
                         "shift_calendar_days", "shift_basis",
                         "parties": {party: days},
                         "cascade_inferred": bool }, ...],
              "column_totals": {party: days},
              "grand_total_shift": int,          # working days (legacy)
              "grand_total_shift_workdays": int,
              "grand_total_shift_calendar_days": int | None,
              "conservation_check": bool,
              "conservation_diff_days": int,
              # Disambiguates "conserved AND attributed" from "conserved
              # but entirely Unattributed". unattributed_share_pct is
              # |Unattributed| / sum|shift| as a percent; the warning
              # flips True when that share is dominant (>= 50%).
              "unattributed_share_pct": float,
              "high_unattributed_share_warning": bool,
              "standard": "AACE RP 29R-03 §3.3.I (apportionment) · §4.2 (concurrency)",
              "data_date_corrections": the record of each update whose
                  data date was moved to its latest actual, and of a
                  baseline with actual dates after its data date
                  ([] on clean files); each is also a data-quality
                  warning
            }
        

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schedulesNo
xer_pathsNo
xer_contentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / schedules
      Added value: +{
      +  "default": null,
      +  "items": {
      +    "additionalProperties": true,
      +    "type": "object"
      +  },
      +  "title": "Schedules",
      +  "type": "array"
      +}
  2. Added
  3. Removed
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so richly: it explains the conservation check semantics, warns that conservation is NOT attribution, describes the unattributed_share_pct/high_unattributed_share_warning fields, flags data-date corrections as quality warnings, and cites the governing AACE standard. This is exactly the behavioral context an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the sibling routing are front-loaded in the first paragraph, and most length is justified return-value documentation. However, the Returns block is verbose, repeating legacy aliases (shift_days/shift_workdays/grand_total_shift) with considerable redundancy that could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description explains the return shape in detail (parties, rows, column_totals, conservation fields, warnings) and covers usage, alternatives, and parameters. Nothing an agent needs to call or interpret the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and does: it documents schedules, xer_paths, and xer_contents individually, states the EXACTLY-ONE constraint, notes the minimum of 2 entries, and explains the hosted/remote vs local use cases. This fully compensates for the undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — building a per-window x per-party concurrent-delay attribution matrix from chronological XER snapshots — and explicitly distinguishes itself from forensic_windows_analysis by contrasting the questions each answers. An agent can tell it apart from its siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool ('when you only need the matrix view') and names the alternative plus the condition selecting it ('use forensic_windows_analysis for the full claim'). It also explains the defensive/attack context on a window-by-window basis, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.