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
12 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.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, ...}, ...],
"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?
Without annotations, the description carries full burden. It explains the conservation rule, the mutual exclusivity of inputs, and details the response fields. However, it does not discuss potential performance implications or data volume constraints, leaving a minor gap.
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 one-line purpose followed by context, usage guidance, parameter details, and return format. It is slightly lengthy but every sentence adds value, justifying its 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 no output schema, the description provides a detailed return structure including all fields, the conservation rule, and references the relevant standard (AACE RP 29R-03 §4.2.B). It is fully self-contained for an agent to understand the tool's behavior and output.
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 compensates fully by explaining the two parameters (xer_paths for local-server, xer_contents for hosted/remote) and the requirement to supply exactly one with at least 2 entries, adding critical meaning absent from 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 the tool builds a per-window per-party concurrent-delay attribution matrix from XER snapshots, and explicitly distinguishes it from the sibling `forensic_windows_analysis` tool, leaving no ambiguity about its specific function.
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 this tool when you only need the matrix view; use forensic_windows_analysis for the full claim,' enabling clear selection between alternatives.
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.
forensic_windows_analysisAInspect
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 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?
No annotations are provided, so the description carries the full burden. It describes the tool's main computations and outputs, including the conservation rule. It also discloses that output_dir uses a tempdir if empty and that dashboard/report paths point to temporary locations. However, it does not explicitly state whether the tool is read-only or discuss performance implications, missing a small piece of transparency.
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 opening, bullet-like output listing, parameter details, and return description. It is front-loaded with the purpose and key outputs. While somewhat lengthy, every section adds value. Small improvements could trim redundant phrasing, but overall it is 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?
Given the complexity of the tool and no output schema, the description provides a good high-level overview of the return value (keys like windows, cumulative, attribution_summary, etc.) and a failure case. It does not detail the structure of nested objects, but it suffices for an agent to understand the tool's capabilities and connect it to sibling tools.
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 explain parameters. It does so comprehensively: explains schedules format with alternatives (xer_path vs xer_content), baseline_idx default, optional project_name, entitlement_milestone, and output_dir behavior. This adds significant meaning beyond the bare JSON 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: running forensic windows analysis on Primavera P6 XER snapshots. It specifies the methodology (AACE RP 29R-03), lists the computed outputs (completion shifts, slip registers, attribution, etc.), and distinguishes it from the sibling tool `concurrent_delay_matrix`, which is used for a subset of results.
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 on when to use the tool ('Use this tool for the full multi-window forensic claim') and when not to ('If you already have a windows result... call concurrent_delay_matrix instead'). It also details parameter requirements (e.g., schedules must have at least 2 entries, each with label and xer_path or xer_content) and defaults.
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?
Without annotations, the description fully shoulders the transparency burden. It includes explicit caveats about the probabilistic nature of midpoint estimates, the averaging of velocity, and the finite-difference acceleration. The response structure is detailed, and the limitations are honestly disclosed.
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, bullet list of metrics, cumulative aggregates, caveats, usage condition, and return format. It is front-loaded with the core purpose, and every sentence adds value without being verbose.
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 and lack of output schema, the description covers the metrics, response structure, and caveats thoroughly. However, it does not clarify that this tool likely requires prior or concurrent use of 'forensic_windows_analysis', which is a dependency. A brief note on prerequisites would make it 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?
Schema description coverage is 0%, so the description must compensate. It only explains that exactly one of 'xer_paths' or 'xer_contents' should be supplied with at least 2 entries, but it does not explain what constitutes a valid XER path or the format of XER text contents. This is insufficient for a tool with two undocumented array parameters.
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 'per-window slip velocity & acceleration trend' and lists the specific metrics. It explicitly distinguishes itself from the sibling tool 'forensic_windows_analysis' by noting it builds on the same math and should be used when a slip-rate trend line is needed.
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 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 a clear conditional for when to choose this tool over its sibling. It does not state when not to use it, but the context is sufficient.
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. 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),
"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 |
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 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, ...}, ...],
"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!