Skip to main content
Glama

cpp-cpm-engine

by io.github.danafitkowski

critical_path_validator

Critical-path validation, logic health, and DCMA-14 assessment of a Primavera P6 schedule.

        Runs the CPP critical-path validator: checks for false
        criticality, constraint-driven CP segments, open ends, broken
        logic, and surfaces a DCMA-14 block with the 14 metrics
        (logic, leads, lags, FS%, hard constraints, high float, high
        duration, invalid dates, resources, missed tasks, critical
        tasks, CPLI, BEI, etc.) at the chosen profile threshold
        (commercial / nuclear / mining). When ``baseline_xer_path``
        is supplied, BEI (Baseline Execution Index) is computed.

        Use this tool to grade a schedule's logic health and find what
        should be fixed before forensic analysis. For the full HTML
        health-dashboard PDF render, use ``dcma14_health_check``.

        Args:
            xer_path: server-side path to the schedule XER.
            xer_content: full text of the schedule XER (alternative for
                hosted/remote use). Supply EXACTLY ONE of path/content.
            project_index: which project to analyze in a multi-project
                XER (0 = first/primary; default).
            profile: DCMA threshold profile -
                'commercial' (default), 'nuclear', 'mining'.
            baseline_xer_path: optional server-side baseline XER for DCMA BEI.
            baseline_xer_content: optional baseline XER text content (alternative).

        Returns:
            Full validator result dict including:
              - 'project_name', 'data_date', 'analysis_timestamp'
              - 'total_activities', 'complete', activity counts
              - 'critical_path_findings': list of issues
              - 'logic_findings', 'constraint_findings'
              - 'overall_rating' / 'overall_score' / 'overall_confidence':
                LOGIC-HEALTH verdict only (open ends, logic continuity,
                critical-path correctness, constraints, lags). NOT a full
                schedule-health verdict.
              - 'overall_rating_scope': always 'logic_health';
                'overall_rating_label': 'Logic Health'. Use these so the
                headline cannot be read as full DCMA schedule-health.
              - 'dcma_worst_severity': the embedded DCMA-14 worst severity
                (BLOCK/RED/WARN/INFO/PASS) surfaced at the top level so a
                DCMA hard stop is visible next to the logic-health rating
                rather than buried in dcma_14.report.summary.
              - 'dcma_blocks_despite_logic_rating': True when DCMA-14 says
                BLOCK/RED even if the logic-health headline reads GREEN/AMBER.
              - 'dcma_14': dict of 14 DCMA metric results
              - 'recommendations': list of remediation suggestions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profileNocommercial
xer_pathNo
xer_contentNo
project_indexNo
baseline_xer_pathNo
baseline_xer_contentNo

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden. It is highly transparent about output semantics, including that overall_rating is logic-health only, the DCMA worst severity is surfaced separately, and BLOCK/RED can appear despite a GREEN logic rating. It does not explicitly state whether the operation is read-only or mutates anything, but the validator/analysis framing strongly implies no side effects.

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-organized with short paragraphs, an Args section, and a Returns bullet list. Each sentence contributes useful semantics for automation. It is slightly verbose in the return-field explanation but overall stays purposeful.

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 has 6 unannotated parameters, no output schema, and high complexity with DCMA-14 metrics, the description provides a complete mental model: what inputs are accepted, how the analysis differs from a full DCMA check, the meaning of the rating scope, and the layout of the result. This is sufficient for an agent to select and invoke the tool correctly.

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 description coverage is 0%, and the description compensates exceptionally. It explains each of the six parameters, including the mutually exclusive xer_path/xer_content relationship, profile thresholds (commercial/nuclear/mining), and optional baseline inputs. It also details the return dictionary, filling the gap left by the absent output 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?

The description states a specific action: validates critical-path logic, health, and DCMA-14 metrics for a Primavera P6 schedule. It clearly distinguishes this tool from sibling dcma14_health_check by positioning this one as logic-health grading and the other as a full HTML dashboard render.

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 when-to-use context: 'Use this tool to grade a schedule's logic health and find what should be fixed before forensic analysis.' It also names the sibling alternative, dcma14_health_check, for the full HTML dashboard render, giving clear exclusion guidance.

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