cpp-cpm-engine
Server Details
Forensic scheduling MCP for Primavera P6 (XER): AACE windows, DCMA-14, Monte Carlo, TIA.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- danafitkowski/cpp-cpm-engine
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 13 of 13 tools scored.
Each tool has a well-defined, distinct purpose with detailed descriptions. Even closely related tools like `critical_path_validator` and `path_explorer` are clearly separated by scope (project-wide vs. activity-specific). The descriptions explicitly cross-reference other tools to guide selection.
All tool names follow a consistent pattern of descriptive noun phrases in snake_case (e.g., `critical_path_validator`, `forensic_windows_analysis`, `monte_carlo_p50_p80`). No mixing of styles or ambiguous verbs.
Thirteen tools cover the full lifecycle of forensic schedule analysis (ingestion, health checks, retrospective/prospective analysis, risk, and reporting) without redundancy. Each tool adds unique value, and the count is appropriate for a specialized MCP server.
The tool set comprehensively covers standard AACE RP methods (windows analysis, collapsed as-built, TIA, concurrency, Monte Carlo SRA, DCMA-14) and includes auxiliary tools for parsing, path tracing, and execution classification. No obvious gaps for the stated domain of construction delay analysis.
Available Tools
13 toolsclaim_workbench_evidence_ledgerAInspect
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.
Args:
folder_path: path to the evidence folder (must exist).
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 | Yes | ||
| project_name | No | ||
| run_forensic | No | ||
| contract_form | No | CCDC2 | |
| original_baseline_xer_filename | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool processes a folder, produces outputs, and optionally runs another tool (run_forensic). However, it does not explicitly state if it modifies any files or require permissions, but the behavioral context of reading and creating files is implied. Could be more explicit about 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 well-structured and front-loaded with purpose, then lists outputs, usage, args, and returns. It is somewhat lengthy but every sentence adds value. Could be slightly more concise, but organized effectively.
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 complexity (6 params, no output schema, no annotations), the description is remarkably complete. It covers purpose, usage context, alternative, all parameters, return structure with possible None fields, and error handling. 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 description coverage is 0%, but the description's 'Args:' section provides detailed explanations for all 6 parameters, including defaults and meanings. This fully compensates, adding meaning beyond the raw 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 purpose: 'analyzes a folder of mixed evidence... and produces a unified workbench dashboard.' It lists specific outputs and mentions it is for starting forensic delay analysis from raw evidence, distinguishing it from forensic_windows_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: '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.' This clearly states when and when not to use, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collapsed_as_builtAInspect
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.5 framing for the dual-method
gap report). 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, ...}, ...],
"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 Base)"
}
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It describes the core algorithm (shortening durations, CPM re-run, cumulative pass) but does not explicitly state that the tool is read-only regarding input files, leaving some ambiguity about 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 well-structured with paragraphs and clear sections, but is lengthy. Some redundancy exists (e.g., method repeated), yet the level of detail is justified by tool 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?
Despite no output schema, the description includes a detailed return value structure, explains the algorithm and dual-method gap, and addresses warnings, providing a complete understanding for an AI 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?
Schema coverage is 0%, but the description comprehensively documents each parameter in the Args section, including structure of delay_events, mutual exclusivity of path/content, and defaults, adding substantial meaning beyond the 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 that the tool implements a collapsed as-built / but-for analysis following AACE RP 29R-03 §3.8, and distinguishes itself from sibling tools by specifying when to use this vs. time_impact_analysis_fragnet.
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?
Explicitly states when to use (e.g., opposing counsel, dual-method validation) and when not to (prospective fragnet), and names the alternative tool, providing clear guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
concurrent_delay_matrixAInspect
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
§4.2.B (concurrent delay apportionment). 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.
Conservation rule (AACE 29R-03 §4.1): the sum of per-party
column totals equals the sum of per-window completion shifts
within ±1 day of rounding. The ``conservation_check`` field on
the response reflects this; ``conservation_diff_days`` carries
the exact gap.
Use this tool when you only need the matrix view; use
``forensic_windows_analysis`` for the full claim.
Args:
xer_paths: chronologically ordered list of server-side XER
file paths (local-server use).
xer_contents: chronologically ordered list of XER text
contents (hosted/remote use). Each element is the full
text of one XER; server writes each to a tempfile.
Supply EXACTLY ONE of paths/contents (lists must have at
least 2 entries either way).
Returns:
{
"parties": ["Owner", "Contractor", "Concurrent",
"Force Majeure", "Unattributed"],
"rows": [{ "window_label", "period_start", "period_end",
"shift_days", "parties": {party: days},
"cascade_inferred": bool }, ...],
"column_totals": {party: days},
"grand_total_shift": int,
"conservation_check": bool,
"conservation_diff_days": int,
"standard": "AACE RP 29R-03 §4.2.B (concurrent delay apportionment)"
}
| Name | Required | Description | Default |
|---|---|---|---|
| xer_paths | No | ||
| xer_contents | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the conservation rule, the conservation_check and conservation_diff_days fields, and the fact that this tool implements a specific apportionment standard. It could mention whether the tool is read-only or has side effects, but the description implies it is a computational analysis with no modifications, which is reasonable.
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 longer than average but each sentence is informative: purpose, standard, sibling comparison, conservation rule, parameter details, and return format. It is well-structured with line breaks, though some redundancy could be trimmed (e.g., the conservation rule is repeated). Overall, it is front-loaded with the most 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 no output schema, the description provides a detailed return format including all fields. It covers parameters, behavior, conservation rule, and even the specific standard. The tool is complex (matrix construction from multiple inputs), and the description leaves no major 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?
The input schema has 0% description coverage, but the description fully explains both parameters: xer_paths for local-server use and xer_contents for hosted/remote use, and clarifies the mutual exclusivity and minimum 2 entries requirement. This adds vital context 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 that the tool builds a per-window x per-party concurrent-delay attribution matrix from XER snapshots. It references the specific standard (AACE RP 29R-03 §4.2.B) and explicitly distinguishes it from the sibling tool forensic_windows_analysis, making the purpose highly specific and 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?
The description explicitly advises when to use this tool (only need the matrix view) versus when to use forensic_windows_analysis (full claim). It also provides precise constraints: supply exactly one of xer_paths or xer_contents, each with at least 2 entries. This gives clear 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_validatorAInspect
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'
- '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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the core validation actions (checks for false criticality, constraints, open ends, broken logic) and return structure comprehensively. No annotations exist, so description carries full burden; it covers main behaviors but omits potential side effects (though likely read-only, not stated).
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?
Well-structured with summary, usage guidance, parameter list, and return description. Slightly verbose but every sentence adds value; efficient for the 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?
No output schema exists, so description must detail return structure. It lists all key result sections: project info, activity counts, findings (critical path, logic, constraint), DCMA-14 metrics, and recommendations. Complete for a validation tool.
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, but the tool's description explains each parameter in detail: requirement to supply exactly one of path/content, defaults for project_index and profile, and optional baseline inputs for BEI computation. Adds significant meaning beyond 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?
Clearly states it validates critical paths, logic health, and DCMA-14 for Primavera P6 schedules. Contrasts explicitly with sibling 'dcma14_health_check' for full HTML dashboard render, providing distinct purpose.
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?
Explicitly instructs to use for grading schedule logic health before forensic analysis. Directly specifies alternative tool 'dcma14_health_check' for full HTML PDF render, creating clear when-to-use and when-not-to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dcma14_health_checkAInspect
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.
REQUIRES BOTH XER inputs — without baseline the report is
structurally complete but most KPIs blank. If you only have
one XER, pass it twice for a synthetic 0-variance run.
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. For
the JSON / dict shape only (no HTML), use
``critical_path_validator`` which exposes the same DCMA-14
block.
=== 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": "..."
}
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: requires both XER inputs, prerequisites (Node + Playwright), error handling, and that content wins over path. It explains the temporary file handling and cleanup, making side effects clear.
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-organized with sections and bullet-like formatting. It front-loads the purpose. While it is lengthy, every sentence adds value and the structure aids readability. A minor reduction could improve conciseness, but it's still very effective.
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, the description details the return format, including inline HTML and transport size considerations. It covers edge cases (single XER, missing inputs) and contrasts with a sibling tool, providing comprehensive context for correct usage.
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?
All 8 parameters are extensively described with usage scenarios, defaults, and interactions (e.g., path vs content). The description compensates fully for the 0% schema coverage, making each parameter's purpose and behavior clear.
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 generates a full schedule health dashboard HTML report covering DCMA-14, CPLI, BEI, variance, and slip register. It also distinguishes itself from the sibling tool 'critical_path_validator' which provides only JSON/dict output.
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?
Explicitly tells when to use this tool (formal HTML deliverable) and when to use the alternative (critical_path_validator for JSON). It also provides detailed guidance on how to pass XER files (path vs content) and what to do when only one XER is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forensic_windows_analysisAInspect
Run forensic windows analysis (AACE RP 29R-03 §3.3, MIP 3.3 Observational / Dynamic / Contemporaneous As-Is — Modified) 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 AACE 29R-03 §4.1 conservation rule (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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: what computations are performed, attribution math satisfying AACE rules, output_dir behavior with tempdir, and error handling. It leaves no major behavioral unknowns.
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 a clear summary, usage guidance, Args, and Returns sections. It is somewhat verbose due to listing many computations, but every sentence adds value. Slightly less concise than ideal but still efficient.
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?
Despite no output schema, the Returns section thoroughly describes the response structure. All aspects of input, behavior, and output are covered. For a complex forensic analysis tool, the description is comprehensive and leaves no 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?
The schema has 0% description coverage, but the description's Args section adds detailed meaning for all 5 parameters: schedules format with alternatives, project_name override, baseline_idx default, entitlement_milestone role, and output_dir lifecycle.
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 runs forensic windows analysis on Primavera P6 XER snapshots and lists specific computations (e.g., completion shifts, slip registers, attribution). It explicitly distinguishes from the sibling tool concurrent_delay_matrix.
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 guidance: use for full multi-window forensic claim, and call concurrent_delay_matrix if only needing the grid view. It also specifies requirements like minimum 2 schedules and chronological order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
monte_carlo_p50_p80AInspect
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 AACE 122R-22 QRAMM
maturity badge 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': {'P10', 'P50', 'P80', 'P90'}
- 'baseline.config': sim params used
- 'baseline.sensitivity': per-activity tornado rows
- '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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the algorithm (sampling from distributions, CPM re-run), input requirements (exactly one of path/content), output details (percentiles, sensitivity), and options for reproducibility (seed) and output location, though it could mention performance implications of 5000 iterations.
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?
Well-structured with a headline, detailed explanation, usage guidance, structured Args list, and Returns section. Every sentence provides essential information without redundancy.
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 9 parameters, no output schema, and no annotations, the description covers purpose, usage, parameter semantics, and return structure comprehensively, including key output paths and optional outputs. It is complete for correct agent invocation.
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?
With 0% schema description coverage, the description fully documents all 9 parameters in the Args section, including defaults, allowed values, and the exclusive constraint between xer_path and xer_content, adding substantial meaning beyond the 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 it performs Monte Carlo schedule risk analysis for P10/P50/P80/P90 completion dates on Primavera P6 schedules, referencing AACE standards and distinguishing from sibling tools like qramm_maturity.
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?
Explicitly says 'Use this tool when you need probabilistic completion forecasts or a tornado/sensitivity ranking' and directs to pipe results into qramm_maturity for QRAMM badge, providing clear when-to-use and when-to-use-alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
path_explorerAInspect
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 24R-03 §4 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes key behaviors: traces predecessors/successors, detects artificial criticality, cites AACE RP 24R-03, supports MCPM and near-critical. Lacks details on error handling or performance but sufficient for a trace 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?
Well-structured with front-loaded purpose, but the Args section repeats some description from the main text. Could be slightly more concise but remains clear and organized.
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?
Returns section documents output structure, all parameters are explained, and context about criticality and standards is included. Complete for a specialized tracing tool with no 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 coverage is 0%, but description contains a full 'Args' section explaining each parameter's purpose, default, and usage notes (e.g., supply exactly one of xer_path/xer_content). Adds significant meaning beyond 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?
Clear verb+resource: 'Logic-trace driver-chain explorer' answering specific questions. Explicitly distinguishes from sibling 'critical_path_validator' by stating its focus on single activity logic chain.
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?
Explicitly states when to use (investigating a single activity's logic chain) and when not (for project-wide audit, use critical_path_validator), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qramm_maturityAInspect
AACE 122R-22 QRAMM maturity tier badge for an SRA result.
Scores a Schedule Risk Analysis run (from
``monte_carlo_p50_p80`` or any equivalent dict) against AACE
RP 122R-22 (Quantitative Risk Analysis Maturity Model)
structure: tier 1 (Initial) through tier 4 (Optimized) per
CMMI-style framing of evidence the SRA carries.
Inputs the SRA inspects (defensively, all keys optional):
- baseline.percentiles (P50 / P80 presence)
- baseline.config (iterations, opt/ml/pes %, distribution)
- baseline.sensitivity (per-activity tornado rows)
- mitigated (scenario comparison evidence)
- risk_register_simulation + risk_register_used
(Hulett qualitative risk register evidence)
- convergence (optional MC convergence diagnostics)
Use this tool any time you have an SRA result and want a
maturity tier suitable for a forensic-claim methodology
section. The badge carries a mandatory caveat that the tier
definitions are an interpretation of typical risk-maturity-
model structure pending confirmation against AACE 122R-22 §3
primary text.
Args:
sra_result: dict from ``monte_carlo_p50_p80``. May be {} -
the badge degrades to Tier 1 with a clear note.
Returns:
{
"rp_citation": "AACE RP 122R-22 ...",
"tier": int (1-4),
"tier_label": "Initial" | "Defined" | "Managed" | "Optimized",
"tier_description": longer interpretive description,
"tier_color": "#xxxxxx",
"evidence": ["..." what the SRA had / lacked],
"gaps_to_next_tier": ["..." concrete advance steps],
"caveat": disclosure string
}
| Name | Required | Description | Default |
|---|---|---|---|
| sra_result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that inputs are optional, degrades gracefully to Tier 1 for empty input, and includes a caveat about interpretation. Missing potential side effects but assumes read-only nature.
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 bullet-point-like listing of inputs. Could be more concise, but the structure aids readability.
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, the description details the return structure. It covers all key aspects of the tool's behavior, making it complete enough for an agent to use properly.
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 only defines sra_result as an object with additionalProperties. The description compensates by listing expected subkeys and their meaning, providing essential semantics beyond the 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 it scores a Schedule Risk Analysis result against AACE RP 122R-22 maturity model, using specific verb 'scores' and specific resource 'SRA result'. This uniquely distinguishes it from sibling tools.
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 tier...' providing clear usage context. It does not mention when not to use, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slip_velocityAInspect
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)
- 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)
Cumulative aggregates ``mean_velocity_days_per_day``,
``max_velocity_window``, 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:
xer_paths: chronologically ordered list of server-side XER paths.
xer_contents: chronologically ordered list of XER text contents
(alternative for hosted/remote use).
Supply EXACTLY ONE of paths/contents (at least 2 entries).
Returns:
{
"rows": [{window_label, period_start, period_end,
window_duration_days, shift_days,
slip_velocity_days_per_day, slip_acceleration,
midpoint_estimate_date,
half_period_estimated_slip_days}, ...],
"cumulative": {mean_velocity_days_per_day,
max_velocity_window,
accelerating_windows,
decelerating_windows,
recovery_windows},
"standard": "AACE RP 29R-03 §3.3 (Windows Analysis)",
"caveat": "..."
}
| Name | Required | Description | Default |
|---|---|---|---|
| xer_paths | No | ||
| xer_contents | No |
Tool Definition Quality
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 transparently describes the three computed metrics, cumulative aggregates, and mandatory caveats about probabilistic estimates. It does not mention destructive actions or auth requirements, but the nature of the tool (read-only analysis) is implied.
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, using bullet points and a code block for the output format. Every sentence contributes value—defining metrics, providing usage guidance, listing caveats, and specifying parameter constraints. Front-loaded with the main purpose.
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, the description provides a detailed return format including the structure of 'rows' and 'cumulative'. It includes caveats, standard reference, and mutual exclusivity of parameters. An agent can use this tool correctly based on the description alone.
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% (neither parameter has a description in the input schema), but the description compensates fully. It explains that exactly one of 'xer_paths' or 'xer_contents' must be supplied, and that at least 2 entries are required. This adds critical semantic meaning beyond the raw 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 computes slip velocity and acceleration per window from XER snapshots, listing three specific metrics. It explicitly distinguishes itself from the sibling tool 'forensic_windows_analysis' by stating it builds on that tool and should be used when a slip-rate trend line is desired.
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.' This provides clear context for when to use it, though it would be improved by also mentioning when not to use it or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
time_impact_analysis_fragnetAInspect
Time Impact Analysis (TIA) — prospective fragnet insertion into a pre-impact baseline schedule.
Implements AACE RP 52R-06 (Time Impact Analysis as Applied in
Construction) — the forward-looking / prospective sibling of
``collapsed_as_built``. For each fragnet (delay-event activity
chain), the activities are inserted into the baseline network,
CPM re-runs, and the resulting completion-date impact (in
calendar days AND project-calendar working days) is reported
per-fragnet plus cumulatively.
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.
baseline_xer_content: full text of pre-impact baseline XER
(alternative for hosted/remote use).
Supply EXACTLY ONE of path/content.
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 -
NOT joint impact)
}
| Name | Required | Description | Default |
|---|---|---|---|
| fragnets | No | ||
| output_dir | No | ||
| project_name | No | ||
| baseline_xer_path | No | ||
| baseline_xer_content | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the process: inserts activities into baseline, reruns CPM, reports per-fragnet and cumulative impacts in calendar and working days. It also discloses the constraint to supply exactly one of baseline_xer_path or baseline_xer_content. No annotations are provided, so the description carries full burden and meets it well.
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 sections for purpose, usage, parameters, and returns. It is slightly lengthy but every sentence adds value. Could be marginally trimmed, but overall efficient and front-loaded.
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?
The description includes the full return type structure in the 'Returns' section, which compensates for the lack of an output schema. It covers all parameters and their nuances, references a relevant standard, and distinguishes from siblings. For a complex tool with nested objects and multiple parameters, this is highly complete.
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 schema has 0% description coverage, the description compensates fully by explaining that baseline_xer_path and baseline_xer_content are alternatives, detailing the fragnets structure (with required fields like id, name, liability, activities, ties), and clarifying output_dir behavior (tempdir if empty). This adds significant meaning beyond the schema's raw properties.
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 purpose: 'Time Impact Analysis (TIA) — prospective fragnet insertion into a pre-impact baseline schedule.' It specifies the AACE standard and distinguishes it from the sibling 'collapsed_as_built' by calling it the forward-looking/prospective sibling.
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 usage guidance: 'Use this tool when modeling delay impact prospectively... For retrospective windows analysis after the fact, use forensic_windows_analysis.' This provides clear when-to-use and when-not-to-use with an alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
woet_classifierAInspect
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 calendar-shaped visualization layer above the AACE MIP
3.4 entitlement layer — 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": MIP-3.4 enhancement citation,
"today": "YYYY-MM-DD",
"project_totals": {progress, gain, extended, void},
"per_activity": [{code, name, baseline_start, ...}, ...],
"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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It thoroughly explains the classification logic, the four day-states, and the output structure. It also clarifies that the tool is not a substitute for AACE 29R-03 §3.7 TIA modeling. While it doesn't discuss performance or side effects, the behavioral description is transparent and complete for the tool's intended use.
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 a clear definition, usage guidance, parameter list, and return format example. It is somewhat lengthy but every sentence serves a purpose. The structure is front-loaded and easy to parse.
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 5 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the methodology, usage context, parameter semantics, and return value shape. It also positions the tool relative to forensic analysis standards and sibling tools, leaving no significant gaps for an AI agent to infer.
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 has 0% description coverage, but the tool description compensates fully. It explains each parameter in the Args section, including the path/content alternatives and the default behavior for 'today'. This adds significant meaning beyond the bare schema, making it easy for an agent to supply correct argument values.
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 defines the tool's purpose: per-activity day-by-day classification of as-built vs. baseline execution into four states (PROGRESS, GAIN, EXTENDED, VOID). It distinguishes itself from sibling tools like time_impact_analysis_fragnet by stating it's a calendar-shaped visualization above the AACE MIP 3.4 layer, not a substitute for fragnet-based TIA.
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 ('when you want a per-activity execution-quality picture') and provides clear instructions for parameters (supply exactly one of path/content per pair). It also clarifies the scope and limitations relative to more detailed forensic modeling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xer_parserAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses that only a table summary is returned, not row-level data, and explains the rationale (context window explosion). The return structure is detailed, including all fields, which compensates for the lack of annotations and output 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 and efficient: first paragraph states the core purpose and key constraint, second paragraph explains usage context, third paragraph details parameters, fourth paragraph shows the return structure. Every sentence adds value, and it is front-loaded with the most important 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 complexity of the tool (parsing a specific file format with many sibling tools), the description is fully complete. It explains the tool's role in a workflow, provides usage guidelines, describes parameters, and gives a full return structure. No output schema is provided, so the detailed return docstring is necessary and sufficient.
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 input schema only has two string parameters with defaults and no descriptions. The description adds crucial semantic information: xer_path is a server-side path, xer_content is an alternative for hosted use, and exactly one must be supplied. This goes well beyond the 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 it parses a Primavera P6 XER file and returns a table summary, distinguishing it from sibling tools that provide per-row analysis. The verb 'parse' and resource 'XER file' are specific, and it explicitly contrasts with deeper analytical tools.
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 to confirm parseability, list tables, view project metadata, and count records before deciding on deeper tools. It names alternatives like forensic_windows_analysis and critical_path_validator, providing clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!