Skip to main content
Glama

p6_health_check

Read-onlyIdempotent

Run a DCMA 14-point health check on a P6 project to assess schedule logic, float, constraints, links, baseline misses, and critical-path validity.

Instructions

DCMA 14 point assessment of the last P6 schedule run (F9). checks: logic, leads, lags, long_lags, fs_links, hard_constraints, high_float, negative_float, high_duration, invalid_dates, resources, missed_tasks, critical_path_test (this server's CPM engine: the earliest lowest-float open task delayed 100 working days must move the project finish as much; not run when the engine does not match the F9, see p6_cpm_validate), cpli, bei; each {count, denominator, pct, threshold, pass, sample (15)}; then key_dates (information only: constraint dates against the must finish date, the work after them and each other; count = issues, pct = constraints with an issue). Open = not completed; LOE and WBS summary activities are left out, also as either end of a link; relationship checks count links whose successor is open. pct must stay at most the threshold, except fs_links (at least), cpli and bei (value at least), compared before rounding; pass is None when not evaluated. Thresholds: the project's Check Schedule settings (PROJPROP schedule_check, limits in hours) when stored, else DCMA defaults (limits 44 d of each calendar; resources has none: not evaluated unless thresholds= sets it); threshold_source says which. thresholds= overrides by check name (not critical_path_test); high_float_days sets the high float limit. lags and fs_links also give ladder_pairs (SS + FF between the same activities with the same lag) and their values without them (information). Logic exempts only the project start and finish milestones (listed); dangling starts and finishes (milestones left out, see p6_dangling) are information only. missed_tasks and bei need a baseline: baseline= (Project ID), else the project baseline; baseline_dates 'current' (actual, else early finish) or 'planned' (its planned finish); a task is missed when not finished or finished on a later day. duration_basis: remaining or original. cpli: working days of the project calendar (calendar days beside it). check= returns that check's full list of items as a page {total, offset, returned, next_offset, rows} with result (the check) instead of the whole report. A full run saves a snapshot for p6_health_check_compare (snapshot.id; save_snapshot=False skips it). The earlier top keys stay: no_predecessor, no_successor, hard_constraints, high_float, negative_float {count, sample}; leads_negative_lag, positive_lags, non_fs_links (links whose successor is open). checks.logic_density (after logic): links whose successor is open / open activities, value at least 1.5 (not in summary or score, which stay the DCMA 14). negative_float.worst and high_float.worst: the open activity with the lowest / highest total float {task_code, task_name, total_float_d}. weighted_score {points, grade, earned, max, checks {name: {weight, status pass / warn / fail / not_evaluated, earned}}}: logic_density 20, logic 20, critical_path_test 15, negative_float 15, high_float 10, hard_constraints 10, high_duration 5, leads 5, lags 5, fs_links 5; pass = the weight, warn = half (a failed at most check up to 2 x its threshold, a failed at least check down to 0.9 x it; no band for a zero threshold), fail = 0, not evaluated left out; points = earned / weight of the evaluated checks x 100; grade A >= 90, B >= 80, C >= 70, D >= 55, else F. engine_version: the CPM engine of the critical path test.

Input Schema

NameRequiredDescriptionDefault
checkNo
limitNoRows per page (max 200).
offsetNoRows to skip: pass next_offset from the previous page.
projectYesProject ID as shown in P6 (p6_list_projects).
baselineNo
thresholdsNo
save_snapshotNo
baseline_datesNocurrent
duration_basisNoremaining
high_float_daysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.0
    • changedInput schema / properties / check / anyOf
      Previous value: -[
      -  {
      -    "enum": [
      -      "logic",
      -      "leads",
      -      "lags",
      -      "long_lags",
      -      "fs_links",
      -      "hard_constraints",
      -      "high_float",
      -      "negative_float",
      -      "high_duration",
      -      "invalid_dates",
      -      "resources",
      -      "missed_tasks",
      -      "critical_path_test",
      -      "cpli",
      -      "bei",
      -      "key_dates"
      -    ],
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "logic",
      +      "logic_density",
      +      "leads",
      +      "lags",
      +      "long_lags",
      +      "fs_links",
      +      "hard_constraints",
      +      "high_float",
      +      "negative_float",
      +      "high_duration",
      +      "invalid_dates",
      +      "resources",
      +      "missed_tasks",
      +      "critical_path_test",
      +      "cpli",
      +      "bei",
      +      "key_dates"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / thresholds / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": {
      -      "type": "number"
      -    },
      -    "description": "Threshold per check, e.g. {'hard_constraints': 1}.",
      -    "propertyNames": {
      -      "enum": [
      -        "logic",
      -        "leads",
      -        "lags",
      -        "long_lags",
      -        "fs_links",
      -        "hard_constraints",
      -        "high_float",
      -        "negative_float",
      -        "high_duration",
      -        "invalid_dates",
      -        "resources",
      -        "missed_tasks",
      -        "cpli",
      -        "bei"
      -      ]
      -    },
      -    "type": "object"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": {
      +      "type": "number"
      +    },
      +    "description": "Threshold per check, e.g. {'hard_constraints': 1}.",
      +    "propertyNames": {
      +      "enum": [
      +        "logic",
      +        "logic_density",
      +        "leads",
      +        "lags",
      +        "long_lags",
      +        "fs_links",
      +        "hard_constraints",
      +        "high_float",
      +        "negative_float",
      +        "high_duration",
      +        "invalid_dates",
      +        "resources",
      +        "missed_tasks",
      +        "cpli",
      +        "bei"
      +      ]
      +    },
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: threshold resolution order (stored PROJPROP settings -> DCMA defaults -> thresholds= override), the pass/warn/fail banding rules, weighted_score arithmetic and grading, and the 'pass is None when not evaluated' convention. It also discloses the side effect that a full run saves a snapshot and how to skip it (save_snapshot=False) — something no annotation conveys. Minor gap: nothing says what happens when the project has no schedule run or the check name is invalid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, but the body is a single semicolon-chained block of several hundred words with no headings, lists or paragraph breaks, mixing output structure, scoring rules and parameter semantics. Very little could be cut without losing information, but the chosen format makes the information expensive to parse — the opposite of what good structure should do.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, no-output-schema, high-complexity tool, the description covers the returned keys (checks, key_dates, weighted_score, engine_version, legacy top keys) and the paging contract, so an agent knows what comes back. What is missing is edge-case behavior (no baseline present, empty schedule, invalid check name) and error signaling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 30% schema coverage, the description carries the burden and does so thoroughly: it defines baseline (Project ID, else project baseline), baseline_dates 'current' vs 'planned', duration_basis remaining vs original, thresholds= override semantics (by check name, not critical_path_test), high_float_days, and check= returning a paged list with result. Essentially every one of the 10 parameters gains meaning absent from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'DCMA 14 point assessment of the last P6 schedule run (F9)', then enumerates every check performed. It distinguishes itself from siblings by naming p6_cpm_validate, p6_dangling and p6_health_check_compare in context. The density of the enumeration makes the core purpose harder to extract than it should be, keeping it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the critical_path_test is 'not run when the engine does not match the F9, see p6_cpm_validate', and snapshot saving points to p6_health_check_compare. However there is no explicit statement of when to pick this tool over p6_critical_path, p6_diagnose or p6_float_analysis, which is the primary selection decision an agent faces.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.