P6 MCP

Overview Schema Source Related Servers Discussions Admin

p6_project_summary

Read-onlyIdempotent

Get a one-call overview of a Primavera P6 project, including key dates, activity and relationship counts, critical-path totals, percent complete, baseline variance, and schedule state.

Instructions

One-call overview of a project (values of the last F9): project (name, calendar), dates (data date, planned start, must finish by, scheduled finish, last schedule run, first start and last finish of the activities, scheduled finish minus must finish by in calendar days and in working days of the project calendar (None when it is unreadable)), activities (by status, by type, open, open milestones), relationships (successor in the project; from and to other projects), critical (counts of open activities, LOE and WBS summary left out, as p6_critical_path), percent_complete (primary = units: actual / at completion units, labor plus nonlabor, P6 Units % Complete as p6_list_wbs; p6_progress_curve gives % of the budget instead; physical: physical % weighted by budget units; duration; activities completed; units_vs_physical_mismatch: activities with units whose physical % and units % differ by more than 0.01 point), baseline (the project baseline, baselines attached, the one used: baseline= else the project baseline, its scheduled finish and data date; every key present, null without a baseline; finish variance = scheduled finish minus the baseline's scheduled finish in calendar days and in working days of the project calendar, baseline planned units % at the data date and spi_units = earned units / baseline planned units, earned value and linear spread as p6_progress_curve), counts (WBS, assignments, resources, calendars, code assignments) and schedule_state.

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_project_summary"
  }
}

Input Schema

Name	Required	Description	Default
`project`	Yes	Project ID as shown in P6 (p6_list_projects).
`baseline`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive, so the safety profile is free. The description earns credit beyond that by disclosing null/edge behavior with no output schema present: dates "None when it is unreadable", baseline keys "every key present, null without a baseline", and the explicit 0.01-point threshold for units_vs_physical_mismatch. It does not cover performance characteristics or pagination/size limits for what is clearly a heavy aggregate call.

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?

A single run-on block of deeply nested parentheses enumerating every returned key. Key operational facts (what it does, what the baseline argument does) are not front-loaded and are hard to extract; a reader must parse the whole wall to find the parameter behavior. Not under-specified, but structurally poor and far longer than needed.

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

Completeness3/5

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

With no output schema, describing return contents is necessary and the description does that thoroughly, including derived-metric definitions (physical vs units %, SPI units, finish variance). However, it omits what an agent most needs for a heavy aggregate on a complex schema: prerequisites (project ID from p6_list_projects), expected size/latency, and clear selection guidance versus the narrower sibling tools.

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

Parameters3/5

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

Schema coverage is 50%: `project` is documented in the schema, but `baseline` (anyOf string/null) has no schema description. The text does convey the override logic – "the one used: baseline= else the project baseline" – which partially compensates, but the phrasing is ambiguous and buried inside a parenthetical about return fields rather than clearly stating that the `baseline` argument selects the comparison baseline. Partial compensation, not full.

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?

"One-call overview of a project" gives a specific verb+resource and scope. It also implicitly distinguishes itself from siblings by naming the equivalents it mirrors (p6_critical_path, p6_list_wbs, p6_progress_curve), so an agent can see this is the umbrella tool versus the single-concern ones. The remainder of the description is a field inventory rather than purpose statement, which dilutes but does not obscure the intent.

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 only implied by "one-call overview" – i.e. reach for this when you want everything at once. There is no explicit when-to-use/when-not, no statement of cost or latency (which matters for a tool returning this many structures), and no routing advice such as "use p6_list_projects first to obtain the project ID". The sibling references describe semantic equivalence of returned values, not tool selection.

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

Deploy Server