Forensic scheduling MCP for Primavera P6 (XER): AACE windows, DCMA-14, Monte Carlo, TIA.
Forensic claim workbench — analyzes a folder of mixed evidence (XER chain + MSG/PDF/DOCX/XLSX correspondence) and produces a unified workbench dashboard.
Built from the real-world workflow where forensic delay
analysis starts from a folder containing schedule updates,
owner correspondence, RFIs, change orders, and meeting
minutes — all mixed together. The workbench produces:
- Evidence ledger (chronological): all artifacts dated and
summarized
- Schedule chain-diff: 14-category manipulation log
(TASKPRED add/remove, constraint flips, retroactive
baseline edits, completion reversals)
- Rolling baseline: per-activity baseline-at-introduction
across the entire XER chain
- Trust score: statistical impossibilities flagged
(zero-duration-variance schedules, no-new-activities,
every-activity-hits-baseline, etc.)
- Slip-to-evidence cross-reference: each forensic slip
auto-paired with documents in its window mentioning
affected activity codes
- Unified HTML dashboard with all of the above
Use this tool when starting forensic delay analysis from raw
evidence. For single-XER-pair forensic with hand-prepared
events, use ``forensic_windows_analysis`` instead.
Two input modes (supply exactly one):
* ``folder_path`` — a server-side evidence folder that already
resolves UNDER the server temp directory (the path guard).
Hosted callers cannot reach a desktop path this way.
* ``evidence_files`` — a CONTENT MANIFEST: a list of
``{"name": str, "content_b64": str}`` entries carrying
base64-encoded file BYTES (handles binary PDF/XLSX/MSG as
well as text). The tool decodes each blob, sanitizes the
filename to a bare basename (rejecting path separators,
``..``, absolute/drive paths, control chars, dot-only
traversal), writes it into a FRESH per-call tempdir under
the allowed server-tempdir root, runs the analysis on that
staged folder, then cleans the staged dir up. Caps: at most
500 files and 60 MB total decoded bytes — an over-cap
manifest returns a clear ``tool_error`` naming the cap and
the actual size (NEVER silently truncated).
Args:
folder_path: path to the evidence folder (mode 1; must
exist and resolve under the server tempdir).
evidence_files: content manifest (mode 2); list of
``{"name": str, "content_b64": str}``.
output_dir: optional dir for outputs (tempdir if "").
project_name: optional override.
original_baseline_xer_filename: optional filename in the
folder identifying the baseline XER.
contract_form: contract template tag (default 'CCDC2').
run_forensic: when True (default), also runs
forensic_windows_analysis on the discovered XER chain.
Returns:
{
"evidence_ledger": {...},
"chain_diff": {...} | None,
"rolling_baseline": {...} | None,
"trust_score": {...} | None,
"cross_reference": {...} | None,
"forensic_result": {...} | None,
"output_files": {...},
"errors": {...} (per-step failure log)
}
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | No | ||
| folder_path | No | ||
| project_name | No | ||
| run_forensic | No | ||
| contract_form | No | CCDC2 | |
| evidence_files | No | ||
| original_baseline_xer_filename | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so comprehensively. It discloses path resolution restrictions, file sanitization rules, per-call tempdir creation and cleanup, size caps (500 files/60 MB), explicit error behavior when over cap, and that run_forensic triggers forensic_windows_analysis. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite its length, the description is well-structured with a purpose-led opening, bulleted output list, explicit usage guidance, two clearly delineated input modes, and an Args/Returns section. Every sentence adds technical or operational value; there is no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity, absence of annotations, and absence of an output schema, the description is exceptionally complete. It covers input modes, security constraints, resource caps, error handling, and the full return shape, leaving an agent with all necessary context 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. Every parameter is explained: folder_path with path guard behavior, evidence_files with exact manifest structure and decoding semantics, output_dir, project_name, original_baseline_xer_filename, contract_form default, and run_forensic default with behavioral implication. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('analyzes') and resource ('a folder of mixed evidence'), and enumerates detailed deliverables (evidence ledger, chain-diff, rolling baseline, trust score, cross-reference, HTML dashboard). It also distinguishes itself from the sibling forensic_windows_analysis by explicitly naming the alternative for single-pair analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this tool when starting forensic delay analysis from raw evidence' and 'For single-XER-pair forensic with hand-prepared events, use forensic_windows_analysis instead.' It also details two input modes and when to use each (folder_path vs evidence_files), including path guard and content manifest specifics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collapsed As-Built / But-For analysis on a post-impact XER.
Implements AACE RP 29R-03 §3.8 Modeled / Subtractive / Single
Base method (paired with MIP 3.3 Windows for the dual-method
gap report per SCL §11.5). Validates a forensic windows
analysis (MIP 3.3) by independently computing the same
project drift via subtractive removal of delays from the
as-built schedule.
For each delay event, the as-built duration of every
``affected_activity`` is shortened by ``impact_days`` (or
removed entirely if ``removal_method="remove"``), then CPM
re-runs and the resulting "but-for" finish date is compared
to the as-built finish. Cumulative pass removes ALL events at
once for a project-level but-for finish.
Use this tool when opposing counsel demands a but-for analysis
or you need a dual-method validation pairing §3.3 (windows) with
§3.8 (collapsed-as-built). For prospective fragnet insertion
(MIP 3.7), use ``time_impact_analysis_fragnet`` instead.
Args:
as_built_xer_path: server-side post-impact XER (after delays incurred).
as_built_xer_content: full text of post-impact XER (alternative for hosted/remote use).
Supply EXACTLY ONE of path/content.
delay_events: list of event dicts. Each must have
``event_id``, ``affected_activities`` (list of
task_codes), and ``impact_days`` (number). Optional:
``removal_method`` ('shorten'|'remove'),
``responsible_party``, ``name``, ``description``.
output_dir: optional output dir for HTML/CSV (tempdir if "").
project_name: optional override.
removal_method: global default 'shorten' or 'remove'.
contractor_filter: when True, exclude contractor-caused
events from the cumulative pass (owner audit mode).
Returns:
{
"as_built_finish": "YYYY-MM-DD",
"per_event_results": [{event_id, but_for_finish,
impact_days_collapsed,
duration_removal_basis,
finish_driver_after_removal, ...}, ...],
# duration_removal_basis discloses WHAT duration was removed
# and on what basis; finish_driver_after_removal discloses
# WHAT drives the but-for finish (incl. whether it is bound by
# the data-date floor) so a reader sees WHY the finish did or
# did not move across data dates.
"cumulative_but_for_finish": "YYYY-MM-DD",
"cumulative_impact_days": int,
"dual_method_gap": dict | None,
"output_files": {...},
"warnings": [...],
"method": "AACE 29R-03 §3.8 (Modeled/Subtractive/Single Simulation)"
}
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | No | ||
| delay_events | No | ||
| project_name | No | ||
| removal_method | No | shorten | |
| as_built_xer_path | No | ||
| contractor_filter | No | ||
| as_built_xer_content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the subtractive mechanism (shortening or removing affected_activities, CPM re-runs), the cumulative-pass behavior, the dual-method gap report, and even the meaning of output fields such as duration_removal_basis and finish_driver_after_removal. This is unusually transparent for a complex forensic scheduling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, the description is well-structured into method overview, use guidance, Args, and Returns. Every sentence contributes substantive information—method citation, dual-method validation, event mechanics, alternative tool, parameter semantics, and output rationale. The length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter, complex analytical tool with no output schema and no annotations. The description fully covers the algorithm, the validation relationship to forensic_windows_analysis, parameter details, return shape, output files, warnings, and method label. It provides a complete operational picture 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. The Args section explains every parameter, including the critical 'Supply EXACTLY ONE of path/content' mutual-exclusion rule, the required structure of delay_events with optional fields, and the global removal_method default. No parameter is left undocumented or ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Collapsed As-Built / But-For analysis on a post-impact XER.' It clearly defines the method (AACE 29R-03 §3.8 Modeled/Subtractive/Single Base) and contrasts with sibling tools by naming time_impact_analysis_fragnet for prospective work, so it is well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Use this tool when opposing counsel demands a but-for analysis or you need a dual-method validation pairing §3.3 (windows) with §3.8 (collapsed-as-built).' It also gives a concrete exclusion with an alternative: 'For prospective fragnet insertion (MIP 3.7), use time_impact_analysis_fragnet instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build the per-window x per-party concurrent-delay attribution matrix from a chronological list of XER snapshots.
Implements the per-window concurrency view per AACE RP 29R-03
§3.3.I (apportionment) and §4.2 (concurrency). Where
``forensic_windows_analysis`` answers "how many days does each
party own across the whole project?", this tool answers "how did
each window distribute its shift across the parties?" — useful
when defending or attacking concurrency findings on a
window-by-window basis.
CPP conservation check, per the AACE 29R-03 §3.3.E.13
requirement that the summed per-period net impacts equal the
difference between the first schedule update and the last
schedule update used in the evaluation: the sum of per-party
column totals equals the sum of per-window completion shifts
within ±1 day of rounding. The column-total definition is this
tool's own bookkeeping, not an AACE rule. The ``conservation_check`` field on
the response reflects this; ``conservation_diff_days`` carries
the exact gap.
IMPORTANT — conservation is NOT attribution. ``conservation_check``
can be True (the columns sum to the grand total) even when 100% of
the shift lands in the Unattributed column, i.e. no party owns any
of the drift. Read ``unattributed_share_pct`` and
``high_unattributed_share_warning`` to know whether a meaningful
apportionment actually occurred. A fully-unattributed matrix
conserves perfectly but attributes nothing — never present its
green conservation check as a validated apportionment.
Use this tool when you only need the matrix view; use
``forensic_windows_analysis`` for the full claim.
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`` (full XER text, hosted/remote use) or
``xer_path`` (server-side path, local use). This is the
preferred input for hosted/remote clients.
xer_paths: legacy chronologically ordered list of server-side
XER file paths (local-server use).
xer_contents: legacy chronologically ordered list of XER text
contents. Each element is the full text of one XER.
Supply EXACTLY ONE of schedules / xer_paths / xer_contents
(lists must have at least 2 entries either way).
Returns:
{
"parties": ["Owner", "Contractor", "Concurrent",
"Force Majeure", "Unattributed"],
# Unit for every shift_* field and the grand totals. Always
# "working_days" — the matrix measures the completion shift
# in working days (Dana default). The *_calendar_days twins
# express the SAME shift in calendar days so an unlabeled
# "11" can never be mistaken for the 15-calendar-day value.
"shift_unit": "working_days",
"rows": [{ "window_label", "period_start", "period_end",
# shift_days == shift_workdays (working days,
# legacy alias). shift_calendar_days is the same
# shift in calendar days; shift_basis names the
# finish driver the shift was measured on.
"shift_days", "shift_unit", "shift_workdays",
"shift_calendar_days", "shift_basis",
"parties": {party: days},
"cascade_inferred": bool }, ...],
"column_totals": {party: days},
"grand_total_shift": int, # working days (legacy)
"grand_total_shift_workdays": int,
"grand_total_shift_calendar_days": int | None,
"conservation_check": bool,
"conservation_diff_days": int,
# Disambiguates "conserved AND attributed" from "conserved
# but entirely Unattributed". unattributed_share_pct is
# |Unattributed| / sum|shift| as a percent; the warning
# flips True when that share is dominant (>= 50%).
"unattributed_share_pct": float,
"high_unattributed_share_warning": bool,
"standard": "AACE RP 29R-03 §3.3.I (apportionment) · §4.2 (concurrency)"
}
| Name | Required | Description | Default |
|---|---|---|---|
| schedules | No | ||
| xer_paths | No | ||
| xer_contents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses several critical nuances: conservation is not attribution, the meaning of unattributed_share_pct and its warning, the distinction between working days and calendar days, and the CPP conservation check. This goes far beyond a basic description and prevents misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear paragraphs and an Args/Returns layout. The first sentence is front-loaded and specific. While every part adds value, the detailed Returns block is verbose and could be trimmed without losing critical meaning, though the lack of an output schema makes the detail useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description is effectively complete. It documents all return fields, units, conservation flags, and the unattributed share metadata. It also covers usage context, input constraints, and the distinction from a sibling tool, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so thoroughly in the Args section, detailing the structure of schedules, xer_paths, and xer_contents, and emphasizing the 'EXACTLY ONE' rule. It also clarifies legacy vs. preferred input, adding substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Build the per-window x per-party concurrent-delay attribution matrix from a chronological list of XER snapshots.' It also distinguishes this tool from sibling forensic_windows_analysis by contrasting the questions each answers, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this tool when you only need the matrix view; use forensic_windows_analysis for the full claim.' It also clarifies the mutually exclusive input parameters and the requirement of at least 2 entries, providing clear and actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | commercial | |
| xer_path | No | ||
| xer_content | No | ||
| project_index | No | ||
| baseline_xer_path | No | ||
| baseline_xer_content | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| debug | No | ||
| output_path | No | ||
| timeout_seconds | No | ||
| current_xer_path | No | ||
| baseline_xer_path | No | ||
| return_html_inline | No | ||
| current_xer_content | No | ||
| baseline_xer_content | No |
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.
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.
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.
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.
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.
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.
Run forensic windows analysis (AACE RP 29R-03 §3.3, MIP 3.3 Observational / Dynamic / Contemporaneous As-Is) across multiple Primavera P6 XER snapshots and return the full analysis dict.
This is the headline forensic tool — it computes per-window
completion shifts, per-window slip registers (per-activity slip
with critical/non-critical flag), per-window duration growth on
critical-path activities, per-window per-party attribution
(Owner / Contractor / Concurrent / Force Majeure / Unattributed),
and cumulative project drift from baseline. The attribution math
satisfies the CPP conservation check, per the AACE 29R-03
§3.3.E.13 requirement that the summed per-period net impacts
equal the difference between the first schedule update and the
last schedule update used in the evaluation (per-party day
buckets sum to project drift within ±1 day, no cascade-double-
counting).
Use this tool for the full multi-window forensic claim. If you
already have a windows result and only want the per-window ×
per-party grid view, call ``concurrent_delay_matrix`` instead.
Args:
schedules: list of dicts in chronological order. Minimum 2
entries (baseline + at least one update). Each dict
must contain ``label`` (str) and EXACTLY ONE of:
- ``xer_path`` — server-side filesystem path, OR
- ``xer_content`` — full XER text content.
Use ``xer_content`` when calling a hosted MCP server
from a remote client whose XER lives locally.
project_name: optional override; auto-picked from XER if "".
baseline_idx: which entry in ``schedules`` is the contract
baseline (default 0 = first one).
entitlement_milestone: optional task_code (e.g.
"Ready for Takeover") — recorded on the result, not used
for math.
output_dir: optional dir for HTML dashboard / DOCX report.
If "", a tempdir is used and dropped after — the
dashboard / report paths in the response will point to
the temp location (caller responsible for moving them).
Returns:
{
"analysis": full dict from run_windows() with keys:
"windows", "cumulative", "baseline_label", "data_dates",
"attribution_summary", "mcpm_attribution", ...,
"dashboard": path to HTML dashboard (server-side),
"report": path to DOCX executive report (server-side),
"baseline_stability": {"worst_severity", "has_block", ...}
}
On failure: {"error": "..."} with no schedules processed.
| Name | Required | Description | Default |
|---|---|---|---|
| schedules | Yes | ||
| output_dir | No | ||
| baseline_idx | No | ||
| project_name | No | ||
| entitlement_milestone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden and does so thoroughly. It explains the tempdir behavior and caller responsibility, the failure response format ('{"error": "..."} with no schedules processed'), and the CPP conservation-check expectation of the attribution math.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose statement, usage guidance, Args, and Returns sections. Although long, every sentence contributes operational or decision-relevant detail; there is no padding or repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-parameter tool with no output schema and no annotations, so the description must provide selecting/invoking context, parameter semantics, output shape, failure behavior, and sibling differentiation. It delivers all of these, including the key return keys and file artifacts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. It defines schedules structure in detail, including chronological ordering, minimum count, label requirement, and the exactly-one-of xer_path/xer_content rule, plus semantics for baseline_idx, output_dir, project_name, and entitlement_milestone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run forensic windows analysis across multiple Primavera P6 XER snapshots and return the full analysis dict.' It also names the differentiating sibling tool, concurrent_delay_matrix, clarifying that this tool covers the full multi-window claim rather than just the grid view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use this tool for the full multi-window forensic claim') and points to the alternative for narrow use ('If you already have a windows result and only want the per-window × per-party grid view, call concurrent_delay_matrix instead'). It also gives practical guidance on xer_path vs xer_content for hosted/remote usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monte Carlo Schedule Risk Analysis — P10/P50/P80/P90 completion-date forecast for a Primavera P6 schedule.
Implements an AACE-style quantitative SRA (the same math as
CPP's browser Tool_11 Portfolio Risk Engine, scripted Python
counterpart). For each iteration, every activity duration is
sampled from the chosen distribution (Triangular, BetaPERT,
Uniform, Lognormal, etc.) parameterized by % of baseline
duration; CPM re-runs and the project finish date is recorded.
After all iterations, P10/P50/P80/P90 completion dates and a
sensitivity tornado (per-activity correlation to project
finish) are reported.
Use this tool when you need probabilistic completion forecasts
or a tornado/sensitivity ranking. For the QRAMM-aligned
five-level maturity badge (AACE 122R-22) on the result,
pipe the response into
``qramm_maturity``.
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.
iterations: number of MC iterations (default 5000).
distribution: 'Triangular', 'BetaPERT', 'Uniform',
'Lognormal' (case-insensitive — passed through).
optimistic_pct, most_likely_pct, pessimistic_pct: %
of baseline duration for the distribution params
(defaults: 85 / 100 / 120).
seed: optional fixed seed for reproducibility (0 = system
entropy = non-reproducible).
output_dir: optional output dir; tempdir if "".
Returns:
Full SRA result dict, key paths:
- 'baseline.percentiles': lowercase p-keys
{'p10','p25','p50','p75','p80','p85','p90','p95'},
each {'day', 'date'}. NOTE: keys are lowercase — read
result['baseline']['percentiles']['p80'], not 'P80'.
- 'baseline.config': sim params used
- 'baseline.sensitivity': per-activity tornado rows
- 'risk_register_simulation.percentiles' (only when a
risk_register is supplied): SAME lowercase convention,
{'p10','p50','p80','p90'} each {'day', 'date'}.
- 'project_name', 'data_date', ...
- HTML / DOCX paths if outputs emitted
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| xer_path | No | ||
| iterations | No | ||
| output_dir | No | ||
| xer_content | No | ||
| distribution | No | Triangular | |
| optimistic_pct | No | ||
| most_likely_pct | No | ||
| pessimistic_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the simulation process (sampling, CPM re-runs, record finish dates), the lowercase key convention in output (e.g., 'p80' not 'P80'), the requirement to supply exactly one of xer_path/xer_content, and distribution parameterization. These are non-obvious behavioral details that help avoid misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is well-structured with sections for purpose, args, and returns. The first sentences immediately convey the tool's core purpose. Each sentence adds value, including the crucial key-format caveat and the alternative input methods. There is no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description is exceptionally complete. It details all inputs, explains the output structure with concrete key paths and conventions, and even notes conditional outputs (risk_register_simulation). It also covers edge cases like the path/content exclusivity and seed behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains every parameter: xer_path, xer_content (with exclusivity), iterations, distribution (with case-insensitivity), the three percentage parameters with defaults, seed (with 0 meaning non-reproducible), and output_dir. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Monte Carlo Schedule Risk Analysis — P10/P50/P80/P90 completion-date forecast' and mentions sensitivity tornado ranking. It clearly distinguishes this tool from siblings (e.g., critical_path_validator, deterministic schedule tools) by focusing on probabilistic outcomes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct guidance: 'Use this tool when you need probabilistic completion forecasts or a tornado/sensitivity ranking.' It also names an alternative for a related use case: pipe the response into qramm_maturity for a QRAMM-aligned maturity badge, and implies deterministic analysis is not its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logic-trace driver-chain explorer — answers "WHY is this activity critical?" and "WHAT does it drive?".
Traces driving predecessors backward from a target activity to
project start (the "why critical" chain) and/or driving
successors forward to project finish (the "what it drives"
chain). Detects constraint-driven artificial criticality and
cites AACE RP 49R-06 when found. Supports multiple parallel
critical paths (MCPM) and near-critical paths.
Use this tool when investigating a single activity's logic
chain. For a project-wide CP / logic health audit, use
``critical_path_validator``.
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.
target_activity_codes: list of task_codes to trace; if
empty, all CP / near-critical endpoints are traced.
direction: 'backward' (predecessors), 'forward'
(successors), or 'both' (default).
include_near_critical: also trace near-critical endpoints
(within float band).
output_dir: optional dir for HTML / CSV / JSON outputs.
Returns:
{
"paths": [{chain dicts ...}],
"output_files": {dashboard, csv, json},
"project_finish": "YYYY-MM-DD",
"project_name": ...,
"data_date": ...
}
| Name | Required | Description | Default |
|---|---|---|---|
| xer_path | No | ||
| direction | No | both | |
| output_dir | No | ||
| xer_content | No | ||
| include_near_critical | No | ||
| target_activity_codes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it discloses the forward/backward tracing behavior, the AACE RP 49R-06 citation when artificial criticality is detected, the EXACTLY ONE constraint on xer_path/xer_content, and the HTML/CSV/JSON file side effects. It does not disclose error behavior (e.g., invalid XER or missing target activity), which keeps it just shy of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a punchy two-question hook, followed by dense technical detail, then a clear Args section with one-line meanings per parameter and a Returns JSON example. Every sentence earns its place; the structure makes scanning fast despite the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex analysis tool with 6 params, no annotations, and no output schema, the description is remarkably complete: it covers the analysis domain (MCPM, near-critical, artificial criticality), the input constraint, parameter defaults, and the full return shape including output_files, project_finish, project_name, and data_date. The presence of the return structure removes the need for an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate — and it does. All 6 parameters receive meaningful semantics beyond their bare schema titles: mutual exclusivity for xer_path/xer_content, default behavior for empty target_activity_codes, direction enum values with default, and the float-band meaning of include_near_critical. This is exactly what an agent needs to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line uses a specific verb-resource framing ('Logic-trace driver-chain explorer') and immediately answers the two motivating questions: 'WHY is this activity critical?' and 'WHAT does it drive?'. It clearly distinguishes from siblings by scoping to a single activity's logic chain and explicitly naming critical_path_validator as the tool for project-wide audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this tool when investigating a single activity's logic chain. For a project-wide CP / logic health audit, use critical_path_validator.' This names the alternative tool and the differentiating scope, leaving no ambiguity about when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
QRAMM-aligned maturity reading for an SRA result.
Places a Schedule Risk Analysis run (from
``monte_carlo_p50_p80`` or any equivalent dict) on the five
named maturity levels of AACE RP 122R-22 (Quantitative Risk
Analysis Maturity Model), section 3: level 1 Reactive,
level 2 Ad-hoc, level 3 Centralized, level 4 Dynamic,
level 5 Adaptive.
Inputs the SRA inspects (defensively, all keys optional):
- baseline.percentiles (lowercase p50 / p80 presence)
- baseline.config (iterations, opt/ml/pes %, distribution)
- baseline.sensitivity (per-activity tornado rows, on_cp)
- mitigated (scenario comparison evidence)
- risk_register_simulation + risk_register_used
(Hulett quantified risk register evidence)
- convergence (MC diagnostics, required for level 5)
Use this tool any time you have an SRA result and want a
maturity reading for a forensic-claim methodology section.
Note the scope limit the badge carries on every render: AACE
122R-22 assesses the quantitative-risk capability of an
ORGANIZATION and states it is guidelines rather than a
standard, so a reading on one simulation run is CPP's
placement on the RP's scale, not a QRAMM score. Report it as
"QRAMM-aligned", never as "per AACE 122R-22".
Args:
sra_result: dict from ``monte_carlo_p50_p80``. May be {} -
the badge degrades to level 1 with the missing
evidence listed.
Returns:
{
"rp_citation": "AACE RP 122R-22 ...",
"scale_max": 5,
"scale_note": "... names five levels ...",
"level": int (1-5),
"level_name": "Reactive" | "Ad-hoc" | "Centralized"
| "Dynamic" | "Adaptive",
"level_label": "Level 3: Centralized",
"level_description": what CPP requires of a run there,
"level_color": "#xxxxxx",
"evidence": ["..." what the SRA had / lacked],
"gaps_to_next_level": ["..." concrete advance steps],
"caveat": scope-limit string
}
The keys "tier", "tier_label", "tier_description",
"tier_color" and "gaps_to_next_tier" are retained as
aliases carrying the same five-level values.
| Name | Required | Description | Default |
|---|---|---|---|
| sra_result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the tool's behavior: it inspects specific fields (baseline.percentiles, baseline.config, etc.), degrades to level 1 for empty input, and outputs a structured result with evidence and gaps. It also explains the aliases in the return value. This provides comprehensive transparency beyond the simple schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, caveat, args, returns) but is somewhat verbose, repeating the level names and containing redundant phrasing. It could be tightened without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description fully specifies the return structure, including all keys and their meaning, and the scope limitation. It also covers the input requirements and the degradation behavior, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
For the single parameter sra_result, the description explains it is a dict from monte_carlo_p50_p80, may be empty, and that an empty dict results in level 1 with missing evidence listed. It also enumerates the specific subfields the tool inspects, greatly enriching the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it 'Places a Schedule Risk Analysis run on the five named maturity levels of AACE RP 122R-22', naming the specific standard and levels. It distinguishes itself from sibling tools by focusing on maturity assessment rather than direct delay or risk analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool any time you have an SRA result and want a maturity reading for a forensic-claim methodology section.' It also notes the input source (monte_carlo_p50_p80) and provides a scope-limit caveat, giving clear when-to-use guidance and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
Numerator is the WORKING-day completion shift. The
denominator is WORKING days between the prior and later
data dates on the same calendar
(``window_duration_workdays``), making this a same-day-type
working-day/working-day rate. It falls back to CALENDAR days
only for legacy window dicts that predate that field, and
such a row is flagged ``velocity_basis="wd/cd"``. Read
``velocity_basis`` to know which denominator produced the
figure.
Each velocity field name states the ratio it holds:
``slip_velocity_workdays_per_workday`` (populated only on
the wd/wd path), ``slip_velocity_workdays_per_calendar_day``
(working-days of slip per CALENDAR day elapsed, computed
against ``window_duration_days``), and
``slip_velocity_days_per_day`` as the retained back-compat
name for whichever basis was selected. Quote ``basis`` in
any expert report.
NOTE (2026-09-03): the two named fields are no longer equal.
``slip_velocity_workdays_per_calendar_day`` used to be a
blind copy of the headline velocity, which made its name
wrong once the denominator moved to working days — it read
5/10 = 0.500 while its name promised 5/14 = 0.357. It now
holds the calendar-day rate it is named for.
- 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`` plus a
mean per basis — ``mean_velocity_workdays_per_workday`` and
``mean_velocity_workdays_per_calendar_day`` — each computed
only from the rows that actually carry that denominator, so a
mean is never labelled with a basis it did not use (None when
no window carried it). ``velocity_basis_set`` lists the bases
present and ``velocity_units`` describes them, including an
explicit MIXED string when a run spans both.
Also ``max_velocity_window`` and 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,
velocity_basis,
slip_velocity_days_per_day,
slip_velocity_workdays_per_workday,
slip_velocity_workdays_per_calendar_day,
velocity_field,
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_workday,
mean_velocity_workdays_per_calendar_day,
velocity_basis_set,
velocity_units, max_velocity_window,
accelerating_windows,
decelerating_windows,
recovery_windows},
"units": "working-days of slip per working-day elapsed"
" (wd/cd fallback wording on legacy windows;
" MIXED when a run spans both)",
"basis": "<numerator/denominator day-type disclosure>",
"standard": "AACE RP 29R-03 §3.3 (Windows Analysis)",
"caveat": "..."
}
| Name | Required | Description | Default |
|---|---|---|---|
| schedules | No | ||
| xer_paths | No | ||
| xer_contents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility, and it delivers: it explains the working-day vs calendar-day denominator fallback and the `velocity_basis='wd/cd'` flag, warns that the two named velocity fields are no longer equal, and includes honest caveats that midpoint estimates are probabilistic centroids and acceleration is a finite difference. This is far beyound what a normal description provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long because the tool is inherently complex, but every section is purposeful: front-loaded purpose, metric-by-metric definitions, a historical correctness note, caveats, input rules, and a full return shape. The bulleted structure makes the volume scannable and there is no repetition or off-topic content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description compensates with a full `Returns` object enumerating all row fields, cumulative aggregates, units, basis disclosure, and standard reference. It also explains when the MIXED basis string appears and what `velocity_basis_set` reports. An agent has everything needed to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has zero descriptions for the three parameters, the description fully compensates: it specifies that `schedules` is a chronological list of dicts matching `forensic_windows_analysis` shape with exactly one of `xer_content`/`xer_path`, marks `xer_paths` and `xer_contents` as legacy alternatives, and states the exactly-one and at-least-two constraints. No parameter meaning is left to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with 'Per-window slip velocity & acceleration trend across XER snapshots' and then 'Computes three signed metrics per window', which gives a specific verb-resource pair plus the exact domain. It also distinguishes itself from the sibling `forensic_windows_analysis` by stating that it builds the same per-window math into a trend line, so an agent can immediately tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool when you want a slip-rate trend line on top of the same per-window math forensic_windows_analysis already computes', naming the sibling and the selective condition. It also gives concrete input-mode rules: supply `schedules`, `xer_paths`, or `xer_contents`, exactly one of them, and at least two entries, leaving no ambiguity about how to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time Impact Analysis (TIA) — prospective fragnet insertion into a pre-impact baseline schedule. Supports two modes.
**Single-base mode** (legacy): supply ``baseline_xer_path`` or
``baseline_xer_content``. All fragnets are inserted into the
same shared baseline XER and impact is measured against that
shared baseline. The result carries a
``single_base_disclosure`` warning explaining this is an AACE
29R-03 §3.7 simplification — acceptable when all events share
a single baseline window, but not strict MIP 3.7 Multiple
Base.
**Multi-base mode** (AACE 29R-03 MIP 3.7 Multiple Base):
supply ``per_event_bases`` — a dict keyed by each fragnet's
``id``, with each value a dict containing EITHER
``xer_path`` OR ``xer_content`` for that event's
pre-event contemporaneous baseline. Each fragnet is inserted
into its OWN base, impact is measured against THAT base's
pre-event finish, and the result carries
``per_event_methodology``, ``per_event_base_count``, and
``per_event_bases_used`` (sha256-truncated content hashes for
audit reproducibility). The cumulative-impact figure carries
``cumulative_caveat`` because the sum of events measured
against different bases is NOT a valid joint impact.
Exactly ONE of {baseline_xer_path, baseline_xer_content,
per_event_bases} must be supplied. Multi-base mode errors out
(returning ``{"error": ...}``) if any fragnet id is missing
from ``per_event_bases``.
Use this tool when modeling delay impact prospectively (e.g.
quantifying RFI / change-order delay before settlement). For
retrospective windows analysis after the fact, use
``forensic_windows_analysis`` (MIP 3.3 windows).
Args:
baseline_xer_path: server-side pre-impact baseline XER
(single-base mode).
baseline_xer_content: full text of pre-impact baseline XER
(single-base mode, hosted/remote use).
per_event_bases: dict {fragnet_id: {"xer_path": "..."}
OR {"xer_content": "<full XER text>"}}
for AACE MIP 3.7 Multiple Base mode.
Example::
{
"F1": {"xer_path": "/tmp/bl_pre_F1.xer"},
"F2": {"xer_content": "<XER text>"},
}
fragnets: list of fragnet dicts. Each must have:
- 'id', 'name', 'liability' (responsible party)
- 'activities': list of {code, name, duration_days,
calendar_id?}
- 'ties': list of {pred, succ, type, lag_days?}
Optional: 'description'.
output_dir: output dir for TIA_Report.txt + CSV (tempdir if "").
project_name: optional override.
Returns:
{
"report": path to TIA_Report.txt,
"impacts_csv": path to TIA_Impact_Details.csv,
"baseline": {"project_finish", "critical_count", ...},
"per_fragnet": [{fragnet_id, name, liability,
completion_before, completion_after,
impact_days, impact_working_days,
affected_activities, status, error}, ...],
"cumulative_days": int (sum of per-fragnet impacts),
"cumulative_basis": str (BOTH modes — states the cumulative
figure is the sum of independent
per-fragnet impacts and overstates joint
impact when fragnets share a path),
"per_event_methodology": str (canonical label),
"per_event_base_count": int (count of unique base XERs),
"per_event_bases_used": {fragnet_id: sha256_hash8} (multi-base only),
"single_base_disclosure": str (single-base only),
"cumulative_caveat": str (multi-base only),
}
| Name | Required | Description | Default |
|---|---|---|---|
| fragnets | No | ||
| output_dir | No | ||
| project_name | No | ||
| per_event_bases | No | ||
| baseline_xer_path | No | ||
| baseline_xer_content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses two modes, error conditions (missing fragnet IDs in per_event_bases return an error), and important caveats such as cumulative_basis overstating joint impact and cumulative_caveat for multi-base mode. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is well-structured with clear mode headers, Args, and Returns sections. Every sentence provides value; while not maximally concise, the complexity of the tool justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects, no output schema), the description is remarkably complete. It covers modes, arguments, return values, error behavior, caveats, and provides an example. The agent has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully. The Args section explains every parameter, including structure for per_event_bases and fragnets, with an example dict. This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Time Impact Analysis (TIA) — prospective fragnet insertion into a pre-impact baseline schedule,' providing a specific verb and resource. It clearly distinguishes itself from sibling forensic_windows_analysis by explicitly contrasting prospective versus retrospective analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this tool when modeling delay impact prospectively... For retrospective windows analysis after the fact, use forensic_windows_analysis (MIP 3.3 windows).' This names the alternative and specifies when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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)
}
| Name | Required | Description | Default |
|---|---|---|---|
| today | No | ||
| actual_xer_path | No | ||
| baseline_xer_path | No | ||
| actual_xer_content | No | ||
| baseline_xer_content | No |
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.
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.
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.
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.
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.
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.
Parse a Primavera P6 XER file and return a TABLE SUMMARY (not the full row-level data — XER row dumps explode the MCP context window).
For each table in the XER, returns the table name, field list,
and record count. Per-row data is intentionally omitted — for
forensic / DCMA / windows analysis use the dedicated tools
(``forensic_windows_analysis``, ``critical_path_validator``, etc.)
which consume the parsed XER internally and return analytical
summaries, not raw rows.
Use this tool to confirm an XER is parseable, list its tables, see
the data date / project name from PROJECT, or count activities in
TASK before deciding which deeper tool to run.
Args:
xer_path: server-side filesystem path to the XER file.
xer_content: full text of the XER file (alternative for
hosted/remote use). Supply EXACTLY ONE of path/content.
Returns:
{
"filepath": absolute path,
"encoding_used": "utf-8" | "cp1252" | ...,
"ermhdr": file header dict (P6 version, export user, etc.),
"tables": [{"name", "fields", "record_count"}, ...],
"table_count": int,
"total_records": int,
"project_summary": {
"proj_id", "proj_short_name", "proj_long_name",
"data_date", "plan_end_date"
} (from first PROJECT row, if any)
}
| Name | Required | Description | Default |
|---|---|---|---|
| xer_path | No | ||
| xer_content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral transparency. It thoroughly discloses that the tool returns a summary, not raw rows, and explains why ('XER row dumps explode the MCP context window'). It also outlines the exact return structure, including encoding, table summaries, and project summary, providing complete insight into behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is longer than minimal, every sentence adds value. It is well-structured with a clear purpose statement, usage context, parameter explanations, and a detailed return format. The information is front-loaded and not repetitive, ensuring concise, purposeful prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of an output schema, the description is remarkably complete. It includes a full return structure with field names and examples, explains the input alternatives, and dictates usage scenarios. This makes the tool fully self-documented and actionable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully explain parameters. It does so: 'xer_path: server-side filesystem path to the XER file. xer_content: full text of the XER file (alternative for hosted/remote use).' It also adds a critical constraint: 'Supply EXACTLY ONE of path/content.' This goes beyond schema alone and gives clear usage semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Parse a Primavera P6 XER file and return a TABLE SUMMARY', specifying the verb 'parse' and the resource 'XER file'. It also differentiates from siblings by explicitly noting that for full row-level analysis, dedicated tools like 'forensic_windows_analysis' and 'critical_path_validator' should be used, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this tool to confirm an XER is parseable, list its tables, see the data date / project name from PROJECT, or count activities in TASK before deciding which deeper tool to run.' It also clearly states alternatives and exclusions, such as omitting raw row data and directing users to dedicated tools for deeper analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Built-environment forecasts, public benchmarks, and permit or zoning readiness through remote MCP.
Free educational MCP for read-only eDiscovery news and TAR/review calculators.
IncidentOracle - 12-tool incident management MCP: triage, BaFin DORA reporting, RCA.
Parametric estimating engine: CESMM4/NRM2/SMM7/MMHW Bills of Quantities for civils assemblies.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
