Skip to main content
Glama

slip_velocity

Per-window slip velocity & acceleration trend across XER snapshots.

        Computes three signed metrics per window from the underlying
        forensic windows analysis:
          - slip_velocity_days_per_day: completion shift / window
            duration (positive = slipping, negative = recovering).
            Numerator is the WORKING-day completion shift. The
            denominator is WORKING days between the prior and later
            data dates on the same calendar
            (``window_duration_workdays``), making this a same-day-type
            working-day/working-day rate. It falls back to CALENDAR days
            only for legacy window dicts that predate that field, and
            such a row is flagged ``velocity_basis="wd/cd"``. Read
            ``velocity_basis`` to know which denominator produced the
            figure.

            Each velocity field name states the ratio it holds:
            ``slip_velocity_workdays_per_workday`` (populated only on
            the wd/wd path), ``slip_velocity_workdays_per_calendar_day``
            (working-days of slip per CALENDAR day elapsed, computed
            against ``window_duration_days``), and
            ``slip_velocity_days_per_day`` as the retained back-compat
            name for whichever basis was selected. Quote ``basis`` in
            any expert report.

            NOTE (2026-09-03): the two named fields are no longer equal.
            ``slip_velocity_workdays_per_calendar_day`` used to be a
            blind copy of the headline velocity, which made its name
            wrong once the denominator moved to working days — it read
            5/10 = 0.500 while its name promised 5/14 = 0.357. It now
            holds the calendar-day rate it is named for.
          - slip_acceleration: velocity[n] - velocity[n-1] (positive
            = slip rate increasing, negative = decelerating/recovery)
          - half_period_estimated_slip_days: shift / 2 (forensic
            "where were we at the midpoint" centroid estimate), in
            WORKING days

        Cumulative aggregates ``mean_velocity_days_per_day`` plus a
        mean per basis — ``mean_velocity_workdays_per_workday`` and
        ``mean_velocity_workdays_per_calendar_day`` — each computed
        only from the rows that actually carry that denominator, so a
        mean is never labelled with a basis it did not use (None when
        no window carried it). ``velocity_basis_set`` lists the bases
        present and ``velocity_units`` describes them, including an
        explicit MIXED string when a run spans both.
        Also ``max_velocity_window`` and accelerating / decelerating /
        recovery window counts.

        Honest caveats embedded in the response (mandatory for expert
        reports): midpoint estimates are probabilistic centroids, not
        observed events; velocity is per-window average, not
        instantaneous; acceleration is a finite difference, not a true
        second derivative.

        Built on top of AACE RP 29R-03 §3.3 windows analysis. Use this
        tool when you want a slip-rate trend line on top of the same
        per-window math ``forensic_windows_analysis`` already computes.

        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`` or ``xer_path``. Preferred input for
                hosted/remote clients.
            xer_paths: legacy chronologically ordered list of server-side
                XER paths.
            xer_contents: legacy chronologically ordered list of XER text
                contents (alternative for hosted/remote use).
            Supply EXACTLY ONE of schedules / xer_paths / xer_contents
            (at least 2 entries).

        Returns:
            {
              "rows": [{window_label, period_start, period_end,
                        window_duration_days, shift_days, shift_workdays,
                        shift_calendar_days,
                        velocity_basis,
                        slip_velocity_days_per_day,
                        slip_velocity_workdays_per_workday,
                        slip_velocity_workdays_per_calendar_day,
                        velocity_field,
                        velocity_units, slip_acceleration,
                        acceleration_units, midpoint_estimate_date,
                        half_period_estimated_slip_days,
                        half_period_estimated_slip_workdays,
                        half_period_units}, ...],
              "cumulative": {mean_velocity_days_per_day,
                             mean_velocity_workdays_per_workday,
                             mean_velocity_workdays_per_calendar_day,
                             velocity_basis_set,
                             velocity_units, max_velocity_window,
                             accelerating_windows,
                             decelerating_windows,
                             recovery_windows},
              "units": "working-days of slip per working-day elapsed"
                       " (wd/cd fallback wording on legacy windows;
                       "  MIXED when a run spans both)",
              "basis": "<numerator/denominator day-type disclosure>",
              "standard": "AACE RP 29R-03 §3.3 (Windows Analysis)",
              "caveat": "..."
            }
        

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schedulesNo
xer_pathsNo
xer_contentsNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  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

A5/5.0
Behavior5/5

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

With no annotations present, the description carries full responsibility, and it delivers: it explains the working-day vs calendar-day denominator fallback and the `velocity_basis='wd/cd'` flag, warns that the two named velocity fields are no longer equal, and includes honest caveats that midpoint estimates are probabilistic centroids and acceleration is a finite difference. This is far beyound what a normal description provides.

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

Conciseness5/5

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

The description is long because the tool is inherently complex, but every section is purposeful: front-loaded purpose, metric-by-metric definitions, a historical correctness note, caveats, input rules, and a full return shape. The bulleted structure makes the volume scannable and there is no repetition or off-topic content.

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?

Given no output schema and no annotations, the description compensates with a full `Returns` object enumerating all row fields, cumulative aggregates, units, basis disclosure, and standard reference. It also explains when the MIXED basis string appears and what `velocity_basis_set` reports. An agent has everything needed to invoke and interpret the result.

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?

Although the input schema has zero descriptions for the three parameters, the description fully compensates: it specifies that `schedules` is a chronological list of dicts matching `forensic_windows_analysis` shape with exactly one of `xer_content`/`xer_path`, marks `xer_paths` and `xer_contents` as legacy alternatives, and states the exactly-one and at-least-two constraints. No parameter meaning is left to the schema alone.

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?

Opens with 'Per-window slip velocity & acceleration trend across XER snapshots' and then 'Computes three signed metrics per window', which gives a specific verb-resource pair plus the exact domain. It also distinguishes itself from the sibling `forensic_windows_analysis` by stating that it builds the same per-window math into a trend line, so an agent can immediately tell them apart.

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?

The description explicitly says 'Use this tool when you want a slip-rate trend line on top of the same per-window math forensic_windows_analysis already computes', naming the sibling and the selective condition. It also gives concrete input-mode rules: supply `schedules`, `xer_paths`, or `xer_contents`, exactly one of them, and at least two entries, leaving no ambiguity about how to call it.

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.

TDQS

A4.7/5.0
Disambiguation4/5

Each tool targets a distinct analytical deliverable (windows analysis, concurrency matrix, slip velocity, TIA, collapsed as-built, SRA, etc.), and descriptions explicitly cross-reference sibling tools to clarify boundaries. Some pairs like critical_path_validator vs dcma14_health_check and forensic_windows_analysis vs concurrent_delay_matrix share inputs and close conceptual territory, but the stated distinctions are clear enough to prevent misselection.

Naming Consistency4/5

All tool names follow a consistent lowercase snake_case style with descriptive noun phrases (e.g., forensic_windows_analysis, slip_velocity, xer_parser), so there is no mixing of conventions. However, the pattern is not verb_noun and a few names embed acronyms or numbers (dcma14_health_check, monte_carlo_p50_p80, woet_classifier), which is a minor deviation from a fully uniform naming scheme.

Tool Count5/5

13 tools is well-scoped for a forensic CPM/schedule delay analysis server. Each tool covers a distinct method or deliverable—parsing, logic health, DCMA-14, windows analysis, concurrency, slip trends, TIA, collapsed as-built, Monte Carlo SRA, maturity assessment, WOET, path tracing, and an evidence workbench—so every tool earns its place without redundancy.

Completeness5/5

The tool surface comprehensively covers the forensic delay analysis lifecycle: input parsing, schedule logic validation, DCMA-14 health assessment, retrospective windows analysis, concurrency attribution, slip trending, prospective TIA, collapsed as-built, probabilistic SRA, maturity rating, execution classification, and raw-evidence workbench. Minor gaps like schedule editing or cost analysis exist but are outside the server's stated forensic-analysis purpose.