Skip to main content
Glama

cpp-cpm-engine

by io.github.danafitkowski

woet_classifier

Worked-vs-On-time Execution Timeline (WOET) per-activity day-by-day classification of as-built execution against baseline.

        For each pairable activity (matched by ``task_code``), classifies
        execution into 4 day-states:
          - PROGRESS: work performed during the baseline-planned window
          - GAIN:     work performed BEFORE the baseline window opened
          - EXTENDED: work performed AFTER the baseline window closed
          - VOID:     baseline-window day where activity was NOT active

        This is a CPP-disclosed enhancement layered on top of AACE
        29R-03 §3.3 Windows Analysis — a per-day execution classifier
        (Progress/Gain/Extended/Void) NOT itself AACE-defined. It is
        not a substitute for fragnet-based AACE 29R-03 §3.7 (TIA)
        modeling. It gives the trier-of-fact a calendar picture of
        how the project executed versus how it was supposed to
        execute, which is otherwise buried in finish-date deltas.

        Use this tool when you want a per-activity execution-quality
        picture (on-time %, count of activities with VOID days, etc.).

        Args:
            baseline_xer_path:    server-side path to baseline XER (target dates).
            actual_xer_path:      server-side path to as-built XER (act dates).
            baseline_xer_content: full text of baseline XER (alternative).
            actual_xer_content:   full text of as-built XER (alternative).
            Supply EXACTLY ONE of path/content per pair.
            today:                optional ISO date (YYYY-MM-DD) reference
                for in-progress activities. Defaults to actual XER's
                last_recalc_date if available, else today's date.

        Returns:
            {
              "method": "WOET",
              "standard": "AACE 29R-03 §3.3 Windows Analysis — per-day execution classification overlay (CPP-disclosed enhancement, not AACE-defined)",
              "today": "YYYY-MM-DD",
              "project_totals": {progress, gain, extended, void},
              "per_activity": [{code, name, baseline_start, ...,
                  "dominant": str ('progress'|'gain'|'extended'|'void'
                      or 'mixed' on a tie),
                  "dominant_tie": bool (True when 2+ states share the top
                      day count — do NOT assert one characterization),
                  "dominant_states": [tied top states, never truncated]},
                  ...],
              "on_time_pct": float (0-100)
            }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
todayNo
actual_xer_pathNo
baseline_xer_pathNo
actual_xer_contentNo
baseline_xer_contentNo

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and excels. It discloses internal classification logic (PROGRESS/GAIN/EXTENDED/VOID), the 'dominant_tie' behavior, default handling for 'today', and the fact that it is a CPP-disclosed enhancement not AACE-defined. It also explains the return semantics in detail, leaving no ambiguity about side effects or default behaviors.

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 description is long but well-structured with clear sections (states, context, usage, args, returns). Every section earns its place, but there is some redundancy, such as repeating the AACE 29R-03 §3.3 reference. A slightly tighter prose would earn a 5, but it is still sufficiently organized and front-loaded with a one-line summary.

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 tool's complexity (5 parameters, no output schema, no annotations), the description is exceptionally complete. It covers input constraints, output structure, default behavior, and conceptual positioning. The detailed Returns section compensates for the missing output schema, and the methodology context helps the agent assess suitability.

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?

The schema provides no descriptions and marks no parameters required, but the description's Args section explains every parameter, including the rule to supply exactly one of path/content per pair. This adds critical meaning beyond the schema, clarifying alternative input methods and constraints.

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 description clearly states a specific verb-resource pair: 'per-activity day-by-day classification of as-built execution against baseline.' It further distinguishes itself from sibling tools by explicitly noting it is not a substitute for fragnet-based AACE 29R-03 §3.7 (TIA) modeling and provides a per-activity execution-quality picture.

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 states when to use it: 'Use this tool when you want a per-activity execution-quality picture' and gives clear exclusions by stating it is 'not a substitute for fragnet-based AACE 29R-03 §3.7 (TIA) modeling.' This provides both positive and negative usage guidance, naming alternate approaches.

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

All cpp-cpm-engine toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources