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).
            MIXED DAY-TYPES — numerator is the WORKING-day completion
            shift, denominator is CALENDAR days between data dates, so
            the value is working-days-of-slip per calendar-day-elapsed,
            NOT a dimensionless rate. The honest-named alias
            ``slip_velocity_workdays_per_calendar_day`` (identical
            value), a per-row ``velocity_units`` string, and the
            top-level ``basis`` field make this explicit. Quote
            ``basis`` in any expert report.
          - 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`` (and its
        honest alias ``mean_velocity_workdays_per_calendar_day``),
        ``max_velocity_window``, 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,
                        slip_velocity_days_per_day,
                        slip_velocity_workdays_per_calendar_day,
                        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_calendar_day,
                             velocity_units, max_velocity_window,
                             accelerating_windows,
                             decelerating_windows,
                             recovery_windows},
              "units": "working-days of slip per calendar-day elapsed",
              "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

TDQS

A4.9/5.0
Behavior5/5

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

No annotations exist, so the description carries full burden. It discloses mixed day-type computation (numerator/denominator), honest aliases, and mandatory caveats (midpoint estimates are probabilistic, velocity is per-window average, acceleration is finite difference). Also states basis field must be quoted in expert reports.

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?

Description is long but well-structured with clear sections for metrics, caveats, args, and returns. No wasted words, though alias repetitions (e.g., slip_velocity_days_per_day vs slip_velocity_workdays_per_calendar_day) could be streamlined; length is justified by the tool's technical complexity.

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 the complexity and lack of output schema, the description fully documents return structure, cumulative fields, units, basis disclosure, and standard reference. It also embeds mandatory caveats and usage notes, making it effectively self-contained for correct invocation and interpretation.

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 has zero description coverage, so the description defines each parameter: schedules as dicts with label and exactly one of xer_content/xer_path, legacy paths/contents, and the 'exactly one' rule. It also explains the shape matches forensic_windows_analysis, adding crucial meaning beyond raw schema types.

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?

Description explicitly states it computes per-window slip velocity & acceleration trend across XER snapshots, specifying three signed metrics and cumulative aggregates. It also distinguishes from sibling forensic_windows_analysis by positioning this as a trend line on the same per-window math.

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?

Provides explicit guidance: 'Use this tool when you want a slip-rate trend line on top of the same per-window math forensic_windows_analysis already computes.' It also details input constraints (exactly one of schedules/xer_paths/xer_contents, at least 2 entries) and preferred vs legacy modes.

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.