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": "...",
              "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.6/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 behavioral burden and does so unusually well: it discloses the working-day vs calendar-day denominator fallback and the velocity_basis flag for legacy windows, the None-when-absent rule for per-basis means, the MIXED units case, a data-quality warnings channel (data_date_corrections), and mandatory honesty caveats distinguishing centroids from observed events and finite differences from true derivatives.

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

Conciseness3/5

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

The first line is a strong front-loaded summary and the Args/Returns blocks are well structured, but the body is bloated: the 2026-09-03 changelog paragraph about a past naming bug and the multi-paragraph re-derivation of each velocity field name read as internal documentation rather than invocation guidance. Substantive, but it could shed roughly a third of its length without losing decision-relevant information.

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 annotations, no output schema, and 0% schema description coverage, the description supplies essentially everything an agent needs: input shapes and exclusivity, the full returned field set, unit/basis semantics, and caveats. Nothing material for correct invocation or interpretation 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% and all three params are undocumented in the schema, yet the description fully compensates: it defines the schedules dict shape (label plus EXACTLY ONE of xer_content/xer_path) and marks xer_paths/xer_contents as legacy alternatives, plus the mutual-exclusion rule and the minimum of 2 entries. This is more than the schema would have provided.

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?

The opening line names the specific verb/resource ('slip velocity & acceleration trend across XER snapshots') and the following paragraph defines the three exact metrics computed. It explicitly distinguishes itself from the closest sibling: 'Use this tool when you want a slip-rate trend line on top of the same per-window math forensic_windows_analysis already computes,' so an agent can route between the two without opening either schema.

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

Usage Guidelines4/5

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

It gives an explicit when-to-use condition and names the alternative tool (forensic_windows_analysis) it builds on. It does not state when NOT to use it or mention the other forensic siblings (time_impact_analysis_fragnet, concurrent_delay_matrix), so routing guidance is clear but not exhaustive.

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.