Skip to main content
Glama

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 CPP's other DCMA-14 engine
        (``critical-path-validator/scripts/dcma14.py``). Since
        7 November 2026 both engines, and CPP Lens, measure to one written
        definition (``_cpp_common/references/DCMA_DEFINITION.md``,
        published at criticalpathpartners.ca/dcma-14-definition.html),
        and every engine's test suite checks it against the same
        hand-worked parity fixtures, check by check and count by count.
        They remain two programs with different outputs: this tool renders
        the client deliverable and grades it A to F (CPP's convention, not
        DCMA's, given only when at least 10 of the 14 are scored); the
        validator returns passed of scored with its own critical-path
        findings. 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; its .manifest.json
                sidecar is written beside it. Left empty, both go in a new
                folder of their own in the server temp directory.
            timeout_seconds: per-step Playwright timeout (default 120s).
                A floor: for the parse and download waits the server
                applies a deadline grown from the activity count of the
                XERs supplied, so large schedules need no larger value.
            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.
            company: optional, the firm the report carries (title block,
                print cover, closing). Blank unless supplied, and blank
                carries no firm and reads its method notes without CPP:
                a hosted run is the caller's document (9 November 2026).

        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; None when fewer
                                            #   than 10 of the 14 are scored
              "health_score": 69,           # gauge percent = round(PASS/SCORED*100)
              "status_band": "YELLOW",      # GREEN | YELLOW | RED; None when not graded
              "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,
                "graded": bool,             # False when fewer than 10 of 14 scored
                "scored_of_14": 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.
                                      #   Both engines measure to the one
                                      #   DCMA definition — 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

NameRequiredDescriptionDefault
debugNo
companyNo
output_pathNo
timeout_secondsNo
current_xer_pathNo
baseline_xer_pathNo
return_html_inlineNo
current_xer_contentNo
baseline_xer_contentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / company
      Added value: +{
      +  "default": "",
      +  "title": "Company",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so thoroughly: it discloses Node + Playwright prerequisites, clear errors when they are missing, optional baseline behavior, degraded-mode semantics, content-over-path precedence, output-path sidecar behavior, timeout handling, and inline HTML transport-size risks. It also clarifies result fields, including tri-state pass values and deprecated aliases, so an agent can interpret the response safely.

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 definition is front-loaded with purpose and key warnings and is organized into clear sections, but it is substantially bloated. Historical bug notes, repeated deprecation warnings, and detailed migration commentary go beyond what an agent needs to select and invoke the tool correctly.

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?

For a complex, prerequisite-heavy report generator with no annotations and no output schema, the description is complete: it covers execution environment requirements, input alternatives, failure modes, degraded-mode interpretation, output paths, response contents, and transport limitations. An agent has enough information to call it correctly and to interpret the result without opening additional documentation.

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%, but the description documents every one of the nine parameters with meaningful semantics: path versus content alternatives, precedence rules, output_path sidecar behavior, the timeout floor and adaptive deadline, debug output, return_html_inline bandwidth implications, and company branding behavior. This fully compensates for the bare input 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 names a specific deliverable — a Full Schedule Health Dashboard HTML report covering DCMA-14, CPLI, BEI, variance, and slip register — with enough specificity that the agent knows exactly what resource is produced. It explicitly distinguishes this tool from critical_path_validator, including why they are not interchangeable and when citing one versus the other matters.

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?

It states when to use the tool ('when you need the formal HTML deliverable'), what not to assume about the sibling validator, and how to choose between *_xer_path and *_xer_content depending on local versus hosted MCP execution. It also explains optional baseline behavior and the degraded-mode consequences, which is exactly the when-to-use nuance an agent needs.

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.