Skip to main content
Glama

cpp-cpm-engine

by io.github.danafitkowski

dcma14_health_check

Full Schedule Health Dashboard HTML report — DCMA-14 + CPLI + BEI + variance/slip register against the baseline.

        Wraps the CPP Schedule Health Review skill, which produces a
        self-contained ~1.3 MB HTML dashboard. The dashboard renders
        DCMA metrics, charts, baseline-vs-current variance, slip
        register, GAO/AACE compliance bands, and a reproducibility
        manifest.

        Baseline XER is OPTIONAL as of Round 7 (Fix MCP-8). When
        omitted, the tool runs in "degraded mode": the current XER
        is used as its own baseline for a synthetic 0-variance run.
        The result carries ``degraded_mode: true`` and
        ``degraded_mode_reason`` explaining that BEI / variance /
        slip register KPIs are NOT meaningful in this mode. Supply
        baseline_xer_path or baseline_xer_content to get the real
        two-XER variance dashboard.

        REQUIRES Node + Playwright on the server (the dashboard renders
        via headless Chromium). The tool returns a clear error if
        either prerequisite is missing.

        Use this tool when you need the formal HTML deliverable.

        Do NOT treat ``critical_path_validator`` as a JSON view of this
        tool. It runs a SECOND, independent DCMA-14 implementation
        (``critical-path-validator/scripts/dcma14.py``) with its own
        criterion numbering, its own activity-eligibility rules and its
        own CPLI definition. Measured across the real-export corpus on
        2026-08-25, the two engines return different verdicts on
        individual criteria for the same XER, and on some criteria they
        differ by construction on every file. Two separate DCMA-14
        implementations, neither derived from the other. Cite one
        engine per matter and name which. If what you wanted was the
        JSON shape of THESE numbers, it is already in this tool's own
        return: ``dcma_14``, ``metrics`` and ``headline`` are extracted
        verbatim from the HTML this call produced, so they cannot
        disagree with the deliverable the client is reading.

        === HOW TO PASS THE XER FILES ===
        For each XER (current, baseline) you supply EXACTLY ONE of:
          - ``*_xer_path``    — filesystem path on the server. Use this
                               when the MCP server runs locally and the
                               file is already accessible to it.
          - ``*_xer_content`` — full text of the XER file as a string.
                               Use this when calling a HOSTED MCP server
                               from your local Claude — the server has no
                               access to your local filesystem, so you
                               must send the content over the wire. The
                               server writes it to a tempfile, runs the
                               pipeline, and cleans up afterward.

        If both are supplied for the same XER, content wins (the path
        is ignored). If neither is supplied, the call returns an error.

        Args:
            current_xer_path:    server-side path to the current XER.
            baseline_xer_path:   server-side path to the baseline XER.
            current_xer_content: full text of the current XER (alternative).
            baseline_xer_content: full text of the baseline XER (alternative).
            output_path: optional output HTML path. Ignored when content
                is supplied (output goes to a tempdir alongside).
            timeout_seconds: per-step Playwright timeout (default 120s).
            debug: pipe Playwright stderr / browser console to stderr.
            return_html_inline: when True (default), the generated HTML
                is read off disk and returned as ``html_content`` in the
                response. Required for hosted/remote use; set False to
                save bandwidth when calling a local server where you can
                open ``html_path`` directly.

        Returns:
            {
              "ok": True,
              "html_path": "absolute path on the server",
              "html_content": "<!DOCTYPE html>..." (when return_html_inline),
              "current_xer": "...",
              "baseline_xer": "...",
              # ── Deliverable headline — the SAME figures the HTML
              # renders in its header / gauge / DCMA footer
              # ("GRADE C · 69% · YELLOW"). Extracted verbatim from the
              # dashboard's embedded payload; NOT recomputed here. These
              # are the authoritative grade for citing the deliverable.
              "grade": "C",                 # letter grade A-F (or None)
              "health_score": 69,           # gauge percent = round(PASS/SCORED*100)
              "status_band": "YELLOW",      # GREEN | YELLOW | RED
              "headline": {                 # full block (None if absent)
                "grade": "C", "grade_label": "Acceptable",
                "health_score": 69, "health_score_exact": 68.75,
                "status_band": "YELLOW",
                "passed": int, "failed": int, "scored": int,
                "not_scored": int,
                "basis": "health_score = round(passed / scored * 100); "
                         "scored excludes not-scored criteria",
              },
              # NOTE: result["health_score"] (the gauge percent) and
              # dcma_14.summary.pass_rate are now the SAME ratio on the
              # SAME basis — PASS / SCORED, where SCORED excludes the
              # unscored (status "NONE" / pass:null) criteria. So
              # round(dcma_14.summary.pass_rate * 100) == health_score
              # (e.g. 0.692 → 69), matching the HTML "69% compliance".
              # (Before 2026-06-28 pass_rate divided by total-criteria —
              # 9/14 = 0.643 — and silently contradicted the 9/13 = 69%
              # dashboard; that is the report-safety bug this fixed.) Cite
              # `health_score` / `grade` / `status_band` for the headline;
              # use dcma_14.summary for the raw criterion tallies.
              "dcma_14": {            # ← sibling of html_content;
                                      #   same dict SHAPE as
                                      #   critical_path_validator's block.
                                      #   The VALUES are this engine's and
                                      #   are not interchangeable with that
                                      #   tool's — see the note above.
                "criteria": {1: {...}, 2: {...}, ...},
                # Each criterion carries `scored` (bool) and a TRI-STATE
                # `pass`:
                #   "scored": True/False  — did the dashboard reach a
                #       PASS/FAIL/WARN verdict? False means the criterion
                #       was NOT evaluated (e.g. C10 Resources when the
                #       TASKRSRC section is absent; status "NONE").
                #   "pass": True   — scored and PASSED
                #   "pass": False  — scored and FAILED/WARNED
                #   "pass": null   — NOT scored (no verdict). null is
                #       distinct from false: to count failed criteria,
                #       filter pass == False (or scored == True and not
                #       pass), NOT pass != True — an unscored criterion is
                #       not a failure. `summary.fail` already excludes it.
                # `scored` = pass + fail + warn (the dashboard's
                # denominator); `pass_rate` = pass / scored, NOT
                # pass / total. `unscored` (status NONE) is excluded from
                # `scored`. In degraded mode `not_applicable` counts the
                # baseline-dependent criteria excluded from the score and
                # `degraded: true` + `degraded_note` are stamped inline.
                "summary": {"total": int, "scored": int, "pass": int,
                            "fail": int, "warn": int, "unscored": int,
                            "pass_rate": float | None},
              },
              "metrics": {            # ← DEPRECATED — alias for dcma_14
                # DEPRECATED. Identical payload to `dcma_14`. Retained
                # for backward-compat with clients written against the
                # pre-Round-4 schema. New code should read `dcma_14`.
                # The `deprecated_alias_for` key is set on every
                # response to make migration explicit. This key may be
                # removed in a future major version.
                "deprecated_alias_for": "dcma_14",
                "criteria": {1: {...}, 2: {...}, ...},
                "summary": {       # identical payload to dcma_14.summary
                  "total": int, "scored": int, "pass": int,
                  "fail": int, "warn": int, "unscored": int,
                  "pass_rate": float | None,
                },
              }
            }

            On error: {"error": "..."}

        Note: the inline HTML payload can be ~1.3 MB. Some MCP transport
        stacks have request/response size limits (typically 5-20 MB).
        For very large XERs / very long dashboards, this may fail at the
        transport layer; in that case set ``return_html_inline=False``
        and arrange to fetch the file from ``html_path`` separately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
debugNo
output_pathNo
timeout_secondsNo
current_xer_pathNo
baseline_xer_pathNo
return_html_inlineNo
current_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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not shy away: it states server prerequisites, degraded mode semantics when baseline is omitted, subset of return payload, HTML sizing and transport-layer failure modes, and point-in-time correction around pass rates, including a historical ReportSafety bug. This gives an agent a rich and honest model of what the tool does beyond simply executing a function.

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 it is well structurered with clear sections (HOW TO PASS THE XER FILES, Args, Returns, Notes) and front-loads the essential deliverable statement. Some historical and deprecation detail could be trimmed without much loss, but the overall structure is justifiable for a tool with 8 params, no annotation content, and no output schema. It is verbose but not innerly padding.

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, 0% schema description coverage, and no annotations or output schema, the description is unusually complete. It describes degraded mode, the full return structure (headline, grade, status_band, dcma_14, metrics, errors), the deprecated alias, the tri-state pass semantics, and transport-level failure handling. An agent could both select and invoke this tool without needing to open any other connectivity.

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 0% description coverage, so the description must compensate, and it does. It documents every parameter (current_xer_path, baseline_xer_path, current_xer_content, baseline_xer_content, output_path, timeout_seconds, debug, return_html_inline), explains approval of the file path vs content, and directly states 'If both are supplied for the same XER, content wins.' It also clarifies when output_path is ignored and what return_html_inline means in local vs hosted terms.

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 opens with a specific verb phrase, 'Full Schedule Health Dashboard HTML report,' and names the exact resource and contents: DCMA-14, CPLI, BEI, variance/slip register. It further disambiguates itself from a near-namesake sibling by explicitly stating that critical_path_validator runs a second, independent DCMA-14 implementation. This gives an agent both a clear purpose and a way to avoid off the high-confusion false pairing.

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 gives an explicit 'Use this tool when you need the formal HTML deliverable' signal and sharply differentiates from critical_path_validator. The XER mounting section also tells the agent exactly which parameter to use for local-server odds vs hosted-server cases, including precedence rules when both are supplied. This goes well beyond a generic description by telling an agent how to route to the right tool.

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