Skip to main content
Glama
Sign In
P6 MCP

P6 MCP

by nizarhamza
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

p6_critical_path

Read-onlyIdempotent

Lists critical and near-critical activities from the last P6 schedule run, using project, total-float, or longest-path modes with adjustable float thresholds.

Instructions

Critical activities of the last P6 schedule run (F9), one page: {total, offset, returned, next_offset, rows, definition, mode_used, threshold_h, counts, schedule_state, note}. mode: project (default) follows the project setting (total float <= its hours threshold, or longest path); total_float uses that hours threshold; longest_path uses P6's driving path flag. float_threshold_days forces total float <= that many days (not with longest_path); min_float_days keeps only total float > that many days (days of each activity's calendar, not with longest_path): min_float_days=0 with float_threshold_days=10 lists the near critical activities. LOE and WBS summary activities are left out (even when P6 flags them), completed ones too unless include_completed=True. Order: total float then start, or float path order for the longest path. counts (open activities except LOE and WBS summary, any page): open, total_float, longest_path, negative_float; excluded_summary = LOE and WBS summary activities that meet the definition and the status filter but are not listed. fields= as in p6_query_activities.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "p6_critical_path"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoproject
limitNoRows per page (max 200).
fieldsNo
offsetNoRows to skip: pass next_offset from the previous page.
projectYesProject ID as shown in P6 (p6_list_projects).
min_float_daysNo
include_completedNo
float_threshold_daysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • addedInput schema / properties / min_float_days
      Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Float Days"
+}
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that LOE and WBS summary activities are excluded even when P6 flags them, that completed activities are dropped unless include_completed=True, the exact ordering (total float then start, or float path order), and the precise semantics of each counts bucket including excluded_summary. That is exactly the kind of behavior an agent cannot infer from readOnlyHint/idempotentHint.

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

Conciseness4/5

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

Dense but nearly every clause carries operational meaning, and the purpose is front-loaded before the mode rules. The mode paragraph is a long run-on of semicolons and parentheticals that costs some readability, but trimming it would lose real constraints.

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 an 8-parameter, no-output-schema tool it documents the return envelope, paging, ordering, exclusions and counts semantics, which is most of what an agent needs to call it correctly. Remaining gaps are the unexplained envelope keys (schedule_state, note, definition) and no mention of failure behavior for an unknown project.

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

Parameters4/5

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

With only 38% schema coverage, the description carries the load and mostly does: mode, float_threshold_days, min_float_days, include_completed and fields (deferred to p6_query_activities) all get meaning, while limit/offset/project are already described in the schema. A few envelope keys (definition, note, schedule_state) are named but never explained, so it falls just short of fully compensating.

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?

States a specific resource and scope: critical activities of the last P6 schedule run, paged, with a named mode axis. An agent can tell it apart from p6_query_activities and p6_float_analysis by the critical-path framing, though the boundary with p6_float_analysis is only implied rather than stated.

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

Usage Guidelines4/5

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

Gives clear guidance on the main variation axis: what 'project' (default), 'total_float' and 'longest_path' each mean, that the day-based thresholds cannot be combined with longest_path, and a worked example (min_float_days=0 with float_threshold_days=10 for near-critical). It does not, however, say when to prefer this tool over p6_float_analysis or p6_query_activities.

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

Deploy Server

Other Tools