Provides tools to analyze and optionally edit Primavera P6 schedules stored in a standalone SQLite P6 database, including schedule analysis, DCMA health checks, progress and cost summaries, comparisons, what-if scenarios, and guarded write operations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@P6 MCP Run a DCMA health check on my P6 schedule"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server that lets an AI assistant (Claude Desktop, Cursor, VS Code, LM Studio, Cline and any other MCP client) analyse, and when you allow it edit, Primavera P6 Professional schedules on your Windows PC: a standalone (SQLite) P6 database, or plain XER files.
P6 MCP is an independent project. It is not affiliated with, endorsed or sponsored by Oracle. Oracle, Primavera and P6 are trademarks of Oracle and/or its affiliates.
Ask your assistant questions such as "what drives the finish date?", "run a DCMA health check", "what changed since the last update?" or "what happens if procurement takes four more weeks?". The server computes the answers; the model explains them.
Schedule analysis: projects and EPS, WBS roll-ups, activities with filters and activity codes, relationships with lag calendars, critical path (total float or longest path), driving path, float paths, where an activity's float comes from, float distribution, look-ahead windows.
Health and progress: DCMA 14-point check with the project's own P6 thresholds (and comparison over time), out-of-sequence progress, dangling and redundant logic, S-curves and earned value at the data date, resource and cost summaries, grouping by status, WBS or code.
Comparisons and what-if: compare two updates or a baseline activity by activity and link by link; a CPM engine that reproduces P6's F9 on the projects it was checked against, for what-if scenarios run in memory, never written.
XER files: inspect, import (new project, baseline, update), export, or analyse XER files alone in read-only XER mode, without a P6 database or P6 installed.
Edits (off by default): durations, constraints, actual dates, progress, relationships, schedule options, deletes, EPS, backups and restore.
Related MCP server: ConstructAI
Download P6MCP-Setup-<version>.exe from Releases
and check it against SHA256SUMS.txt (certutil -hashfile P6MCP-Setup-1.0.0.exe SHA256).
Run it. It installs for your Windows user only (no administrator rights, nothing else to install) and, on the last page, offers to register P6 MCP with every MCP client it finds. Untick the ones you do not want.
P6 MCP Settings opens. Under Database, pick your P6 database (suggestions come from P6's own connection list), click Test connection (read only), then Use this database, and Save.
Restart your MCP client completely.
Until you select and test a database, every tool answers "No database configured. Open P6 MCP Settings to select one."
Release builds are not code signed yet: Windows SmartScreen may warn on first launch ("More info", "Run anyway"). Check the SHA-256 first.
Other packages on the release page: a portable zip (same programs, no installation) and an
MCP bundle (.mcpb) that Claude Desktop installs in one click (server only; you pick the database in
the extension settings).
MCP has no automatic discovery: each client reads its own configuration file. P6 MCP adds (or repairs,
or removes) only its own p6mcp entry in that file, after a timestamped backup, keeping every other
entry, comment and the file's formatting. It refuses a file it cannot parse.
Client | Configuration file |
Claude Desktop |
|
Cursor |
|
VS Code / VS Code Insiders |
|
LM Studio |
|
Cline |
|
The Settings app scans again at every launch and offers to register new clients or repair an entry an update overwrote. For any other client, MCP clients > Other clients gives a configuration snippet (stdio, local HTTP, or VS Code format) to paste.
From the command line (the installer uses the same commands):
& "$env:LOCALAPPDATA\Programs\P6 MCP\p6mcp-server.exe" clients list
& "$env:LOCALAPPDATA\Programs\P6 MCP\p6mcp-server.exe" clients register cursor
Tool profiles: Basic (11 read-only tools, suited to small local models) or Full (all 46).
Writes are off by default. With the Full profile and "Allow write operations", every write takes two calls: a dry run that shows the plan and returns a single-use confirmation token, then, after your explicit yes, the same call with that token. Deleting a project or an activity and restoring a backup also need a confirmation text. If the database changed in between, the write is refused.
A backup is taken before every write (with a retention you choose), writes are refused while P6 is running, and every write goes to the edit log with its parameters.
Writes are refused on a P6 schema version P6 MCP was not tested with, unless you trust it explicitly.
These rules are enforced by the server itself on every call, not only by the Settings window.
Writes go straight to the database and bypass P6's own application logic. P6 MCP updates the audit
fields (update_date, update_user, create_*) the way P6 does and never writes planned, early or late
dates or float: close P6 before writing, then open it and press F9. See SECURITY.md
for the list of what the write tools can change.
P6 MCP runs only on your PC: no cloud component, no telemetry. Its only network request is the optional update check (GitHub releases), which you can turn off under Logs and updates.
The data returned by the tools goes to the AI model your MCP client uses, which may be a cloud service. For confidential schedules, use a local model (for example in LM Studio).
By default each client starts its own server (stdio). Under Server you can switch to a local HTTP server, hosted by the notification area app, for clients that need HTTP or to share one server:
listens on 127.0.0.1 only (http://127.0.0.1:<port>/mcp), with a port check;
every request needs Authorization: Bearer <token>; the token lives in the Windows Credential Manager
(shown masked, copy, regenerate);
Host and Origin headers are checked to block DNS rebinding.
Under Database > Data source, choose XER files only, add one or more XER files and click Load
and check. The files are read into a private read-only copy; every read tool works on it. Load two
updates of the same schedule to compare them: a Project ID already used by the first file gets a ~2
suffix.
Component | Tested |
Windows | Windows 11 |
P6 Professional standalone (SQLite) | 25.12 (schema fingerprint in |
XER files | written by P6 Professional 24.12, and by P6 MCP's own export |
MCP clients | registration tested on sample configuration files of every client listed above; stdio and HTTP tested with the MCP Python SDK client; end-to-end use with each client is in the release checklist |
MCP SDK | mcp 2.3 (1.8 or later supported) |
SQL Server and Oracle P6 databases (P6 EPPM, or P6 Professional with a server database) are not supported.
"No database configured": open P6 MCP Settings, select a database, Test connection, Use this database, Save.
A tool is "not available in the Basic profile": switch to Full under Tools and safety, Save, restart the client.
The client does not show the tools: restart it completely (also from the notification area), then
check MCP clients: the entry may need Repair. Ask the assistant to run p6_diagnose.
"P6 (PM.exe) is running": close P6 before a write.
"Unknown P6 schema": your P6 version was not tested; reads work. You can trust the schema under Database (after a backup).
HTTP server error: Server shows the last error (often a port in use: pick another one).
Logs: Logs and updates > Open log folder (%LOCALAPPDATA%\P6MCP\logs). Settings live in
%APPDATA%\P6MCP\config.json; backups, edit log and XER copies in %LOCALAPPDATA%\P6MCP.
Windows Settings > Apps > P6 MCP for Primavera P6. The uninstaller removes the program, the p6mcp
entries from your MCP clients and the startup entry. Your settings, backups and logs are kept.
python -m venv .venv
.venv\Scripts\pip install -e .[dev]
.venv\Scripts\python -m pytest -q
.venv\Scripts\python -m p6mcp.settings_app # Settings windowTests run on a synthetic P6 database and synthetic XER files built by the tests
(tests/fixtures/make_db.py). Never commit a real schedule, database, XER file or log. Building the
installer and releasing: docs/RELEASING.md.
Apache License 2.0. Copyright 2026 Nizar Hamza. See NOTICE.
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). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | project | |
| limit | No | Rows per page (max 200). | |
| fields | No | ||
| offset | No | Rows to skip: pass next_offset from the previous page. | |
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| include_completed | No | ||
| float_threshold_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses pagination via offset/next_offset, ordering rules (total float then start, or float path order), exclusion of LOE and WBS summary activities, the completed-activity filter, and the exact meaning of each counts bucket. This is behavior an agent could not infer from the structured fields.
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 breadth of information is earned, but it arrives as a dense run-on paragraph led by a literal listing of return keys rather than the tool's purpose. An agent must read several lines of punctuation-heavy prose to extract the mode rules, which could have been structured as short bullets.
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?
With no output schema, the description correctly carries the burden of explaining the return envelope (total, offset, returned, next_offset, rows, counts, schedule_state, note) and the counting semantics. Combined with the mode and exclusion rules, an agent has enough to call and paginate correctly, though project and limit semantics stay thin.
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 only 43% schema description coverage, the description compensates substantially: it defines the semantics of mode values, float_threshold_days (forces total float <= N days, incompatible with longest_path), include_completed, and points to p6_query_activities for field meanings. limit and project remain undocumented beyond their schema stubs, so it is strong but not exhaustive.
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?
Names a specific resource and scope: 'Critical activities of the last P6 schedule run (F9), one page', and enumerates the payload keys returned. It distinguishes itself from the generic sibling p6_query_activities by referencing it only for the shared 'fields' parameter, though it never explicitly contrasts with p6_float_analysis, which is the nearest conceptual 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?
Gives concrete selection conditions for the three modes ('project' follows project setting, 'total_float' uses the hours threshold, 'longest_path' uses P6's driving path flag) and states incompatibilities (float_threshold_days is not used with longest_path). No exclusions or alternatives against sibling tools are offered, but the mode semantics are unusually explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here when a tool reports a configuration problem. Shows the server settings in force (database, tool profile, writes allowed, restart needed), the P6 schema and version detected, whether P6 is running, the backup and edit log folders. Works without a database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely new behavioral context: it operates without a database connection and enumerates the specific diagnostic fields it inspects, which tells the agent what evidence the call produces.
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?
Two sentences, front-loaded with the trigger condition before the enumeration of returned fields. The parenthetical list is dense but every item is informative rather than filler.
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?
There is no output schema, but the description compensates by listing the contents of the diagnostic report, and annotations cover the safety profile. Nothing an agent needs in order to decide to call this and interpret the result is missing.
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?
Zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. No parameter-level confusion is possible for this tool.
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?
Specific verb+resource (diagnose the P6 server configuration) with an explicit enumeration of what it reports: server settings in force, P6 schema/version, running state, backup and edit-log folders. This is clearly distinct from the data-retrieval siblings (p6_list_projects, p6_query_activities, etc.), so an agent can separate it without opening a schema.
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?
"Start here when a tool reports a configuration problem" gives a concrete triggering condition, and "Works without a database" adds a precondition-free usage context. It does not, however, address the nearest sibling p6_health_check, so the boundary between diagnostics and health checking is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total and free float distribution of the open activities (not completed, LOE and WBS summary left out) of the last F9, in days of each activity's calendar. Buckets from edges_days (default -20, -10, -5, 0, 5, 10, 20, 44; 0 is always added): below the first edge, [a, b) below zero, exactly 0, (a, b] above zero, above the last edge, so every value falls in exactly one bucket (compared in hours, never rounded). Each bucket: total_float and free_float counts, their % of the activities, and samples (the sample_size lowest floats). no_value counts activities without a float; all_ranges_covered checks that bucket counts plus no_value equal the activities. stats: min, max, mean and median in days, total floats that are not whole days, negative, zero, critical (project definition). include_milestones=False leaves milestones out; wbs_name_contains and code_type / code_value / include_child_codes filter as in p6_query_activities (code_filter in the result, as there).
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| code_type | No | ||
| code_value | No | ||
| edges_days | No | ||
| sample_size | No | Sample rows per check (max 50). | |
| wbs_name_contains | No | ||
| include_milestones | No | ||
| include_child_codes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description nonetheless adds substantive behavior: exclusions (completed, LOE, WBS summary), bucket semantics including the guarantee that every value lands in exactly one bucket, the wrinkle that comparison happens in hours and is never rounded, and the internal consistency checks (no_value, all_ranges_covered).
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 purpose is front-loaded and nearly every clause carries functional information about bucket boundaries, output fields, or filters. It is a dense single paragraph with no visual structure, which hurts scanability for a long definition, but there is little filler to cut.
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?
For a complex analytical tool with no output schema and low schema description coverage, the description is thorough: it defines the output shape (per-bucket total_float/free_float counts, percentages, samples), the stats block, and the integrity fields. An agent can interpret the result and call the tool correctly without further documentation.
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 only 25%, so the description must compensate. It explains edges_days bucketing in detail, restates sample_size's effect ('the sample_size lowest floats'), clarifies include_milestones, and covers wbs_name_contains / code_type / code_value / include_child_codes by delegating to p6_query_activities. The delegation rather than inline explanation keeps it short of a 5, since the agent must open another tool to fully understand the code filters.
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?
Names a specific computation (total and free float distribution) on a precisely scoped resource (open activities of the last F9), and explicitly excludes completed, LOE and WBS-summary activities. It also names the sibling whose filter semantics it mirrors (p6_query_activities), giving the agent a concrete anchor, though it never contrasts with p6_critical_path, the most adjacent tool.
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?
Usage is implied (analyze float distribution of an activity set) and the filter parameters are explicitly delegated to p6_query_activities, which is useful routing. However, there is no explicit statement of when this tool is preferable to p6_query_activities or p6_critical_path, nor any stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail of one activity: the list fields (see p6_query_activities), secondary constraint, remaining, expected, suspend and resume dates, calendar (hours_per_day converts hours to days), WBS (wbs_code as in p6_list_wbs, wbs_path names), predecessors and successors (first 50 of each, with predecessor_count / successor_count; page further with p6_get_relationships), assignments (resource and role, quantities and costs as stored), activity codes, UDFs and notebooks (first 50 of each), lag_rule and schedule_state.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| task_code | Yes | Activity ID (task_code). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the safety annotations by disclosing result-shaping behavior: predecessors/successors and UDFs/notebooks are truncated to the first 50 with count fields, pagination is available via p6_get_relationships, and hours_per_day converts hours to days. This is exactly the kind of context annotations cannot provide.
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?
Front-loads the core purpose then lists field groups in one dense sentence; every clause maps to a returned element, so little is wasted, though the run-on list is heavy for a single sentence.
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?
With no output schema, the description carries the burden of explaining returns and does so thoroughly, covering list fields, dates, calendar, WBS, relationships, assignments, codes and UDFs, plus truncation limits. An agent knows what to expect before calling.
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?
Both parameters are fully documented in the schema (100% coverage) with enough detail (Project ID per p6_list_projects, Activity ID task_code). The description adds no parameter-level syntax or format detail, so the baseline 3 applies.
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?
States a specific verb and resource ('Full detail of one activity') and enumerates the exact field groups returned. It is clearly distinguishable from p6_query_activities (list fields it references) and p6_get_relationships (paging path it references).
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?
Implied usage is clear ('full detail of one activity', with list fields delegated to p6_query_activities), and it explicitly routes the agent to p6_get_relationships when the capped predecessor/successor lists need more. No explicit 'do not use when' or prerequisites, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relationships of an activity, one page: {total, offset, returned, next_offset, rows, lag_rule}. direction: pred, succ or both. Lag in hours (lag_h) and days (lag_d); lag_rule tells which calendar converts lag days (project schedule option, predecessor calendar by default).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per page (max 200). | |
| offset | No | Rows to skip: pass next_offset from the previous page. | |
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| direction | No | both | |
| task_code | Yes | Activity ID (task_code). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description rightly focuses elsewhere: it discloses the pagination contract (page shape with total/offset/returned/next_offset) and the non-obvious lag_rule calendar-conversion behavior. That is real behavioral context beyond structured fields, though it does not cover errors or empty-result behavior.
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?
Dense and front-loaded: the resource and page shape come first, then parameter semantics. Every clause carries information, though the return-field list and the lag sentences could be labeled more clearly (they read like fragments rather than an organized parameter/return block).
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?
With no output schema, the description usefully enumerates the page fields and explains lag_rule, and annotations carry the safety profile. However, it never says what each row contains (relationship type, successor ID), whether direction=both duplicates rows, or that task_code alone may be ambiguous across projects.
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 80%, so limit/offset/project/task_code are already documented and the baseline is 3. The description adds meaning only for direction (pred/succ/both), and even there it restates the enum literals without expanding the pred/succ abbreviations, so it barely exceeds 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?
States the resource precisely ("Relationships of an activity") and scopes it ("one page"), which clearly separates it from siblings like p6_get_activity or p6_query_activities. It never explicitly contrasts itself with those siblings, but the resource is unambiguous.
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 never says when to call this tool versus p6_get_activity, p6_critical_path, or p6_float_analysis, nor does it state prerequisites (e.g., that an activity's task_code is needed). The only guidance is indirect, via the direction parameter values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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). 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).
| Name | Required | Description | Default |
|---|---|---|---|
| check | No | ||
| limit | No | Rows per page (max 200). | |
| offset | No | Rows to skip: pass next_offset from the previous page. | |
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| baseline | No | ||
| thresholds | No | ||
| save_snapshot | No | ||
| baseline_dates | No | current | |
| duration_basis | No | remaining | |
| high_float_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'A full run saves a snapshot for p6_health_check_compare (snapshot.id; save_snapshot=False skips it).' This indicates a default write/side-effect, which directly contradicts the annotations readOnlyHint=true and idempotentHint=true. Per the rules, a description that contradicts annotations receives a score of 1.
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 and dense, appropriate for the tool's complexity, and front-loads the purpose before diving into check-specific details. However, it could be structured more clearly (e.g., bullet points) and some sentences are overly packed, slightly reducing 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 the tool's complexity, 10 parameters, and no output schema, the description is remarkably complete: it covers all checks, default thresholds, baseline requirements, pagination, snapshot behavior, and edge cases. An agent has enough information to invoke it correctly.
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 schema description coverage at 30%, the description compensates extensively by explaining the semantics of many parameters: check returns a paginated list, thresholds overrides by check name (except critical_path_test), baseline and baseline_dates, duration_basis, high_float_days, save_snapshot, etc. This adds substantial meaning beyond what the schema provides.
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 states a specific verb and resource: 'DCMA 14 point assessment of the last P6 schedule run (F9)' and enumerates the checks, making the tool's purpose unambiguous. It also distinguishes itself from more focused siblings like p6_critical_path and p6_float_analysis by being the comprehensive health check.
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 clear context for using this tool (DCMA assessment) and mentions alternatives for specific conditions (e.g., p6_cpm_validate for critical_path_test when the engine mismatches, p6_health_check_compare for snapshots). However, it lacks an explicit 'use this when' statement or a clear set of exclusions versus other health-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Projects, one page: {total, offset, returned, next_offset, rows}. Row: Project ID, name, data date, planned start, scheduled finish, status (of the project WBS node). EPS nodes are never listed; baselines only with include_baselines=True (baseline_of is set).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per page (max 200). | |
| offset | No | Rows to skip: pass next_offset from the previous page. | |
| include_baselines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real behavioral context beyond that: the exact response envelope, per-row fields including baseline_of, the rule that EPS nodes are never returned, and the condition under which baselines appear. It could add a bit more on paging termination, but this is well past the annotation baseline.
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?
Three tight, front-loaded sentences with no filler, and the response-shape detail is placed first where it is most needed given there is no output schema. Every clause carries 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?
With no output schema, the description usefully documents the return structure and row fields, and with zero required parameters the risk of misuse is low. It is nearly complete for a simple read/list tool; only paging mechanics and sibling routing are left implicit.
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 67%; limit and offset are described in the schema, but include_baselines has no schema description. The description compensates by explaining that baselines are only listed when include_baselines=True and that baseline_of is then set, and by tying offset to next_offset. That covers the one undocumented parameter.
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?
States the resource (projects) and the exact page envelope {total, offset, returned, next_offset, rows} plus row fields, so an agent knows precisely what it gets back. Scope exclusions (EPS nodes never listed; baselines only with include_baselines) further sharpen it. It does not explicitly contrast itself with p6_list_wbs or p6_project_summary, so it stops short of a 5.
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?
Usage is implied by the content: a paginated project listing with an opt-in flag for baselines. There is no explicit when-to-use-vs-alternatives statement (e.g. versus p6_list_wbs or p6_project_summary), and no guidance on how to page other than the passing mention of next_offset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WBS tree in P6 order (each node before its children), one page: {total, offset, returned, next_offset, rows, root}. Row: wbs_id, parent_wbs_id, depth (project node 0), wbs_code (as P6 shows it, e.g. 'PRJ.5.1'), wbs_short_name, wbs_name, children (direct), and with rollups=True the rollup of its whole subtree: activities, open (not completed, LOE and WBS summary left out), not_started, in_progress, completed, min_tf_d and negative_float (open activities, days of each calendar), start, finish (actual, else early), budget_units, actual_units (labor plus nonlabor), units_pct (actual / at completion, as P6 Units % Complete). parent= starts at that WBS code, full or relative to the project node ('5.1'); max_depth counts levels below the start node. root repeats the start node (unplaced = activities outside the tree, when it is the project node).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per page (max 200). | |
| offset | No | Rows to skip: pass next_offset from the previous page. | |
| parent | No | ||
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| rollups | No | ||
| max_depth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond that: pagination via next_offset, the definition of 'open' (not completed, LOE and WBS summary excluded), units_pct as actual/at-completion per P6, and the meaning of root/unplaced. This is exactly the kind of context annotations cannot carry.
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?
Front-loaded with purpose and page shape, which is good, but the body is a single dense run-on sentence covering output fields, rollup definitions, and parameter behavior with minimal structural separation. It is information-dense rather than padded, yet harder to parse than it needs to be.
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?
With no output schema, the description must explain return values, and it does thoroughly (page envelope, row fields, rollup fields). It leaves out failure behavior (e.g. an unknown parent code) and there is no output schema to fall back on, so it is strong but not exhaustive for a 6-parameter 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 coverage is 50%; limit/offset are documented in-schema, but parent, max_depth, and rollups carry no schema description. The description compensates well, defining the accepted parent formats ('full or relative to the project node'), max_depth semantics, and what rollups=True actually adds to each row.
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?
States a specific verb and resource ('WBS tree'), the exact ordering guarantee ('each node before its children'), and the paginated shape. An agent can tell it apart from p6_list_projects or p6_query_activities without opening a schema.
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?
Usage is only implied through parameter semantics: 'parent= starts at that WBS code' and 'max_depth counts levels below the start node' suggest scoping, and rollups=True suggests wanting subtree aggregates. There is no explicit statement of when to prefer this over siblings like p6_query_activities or p6_project_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look-ahead of a project, one page: {total, offset, returned, next_offset, rows, window, data_date, counts, schedule_state, note}. The window starts at the data date (or from_date; a date alone starts at 00:00), lasts days= (default 14) or weeks= calendar days and is half-open [from, to). Listed: not started activities starting in it, open ones finishing in it, not started ones spanning it (start before, finish after), every in-progress activity (include_in_progress=False keeps those finishing in the window) and, with include_completed=True, completed ones whose actual dates overlap it. Open activities use their remaining dates (early when empty) of the last F9. LOE and WBS summary activities are left out. Each row has window: the categories it meets (in_progress, starting, finishing, spanning, completed); counts gives them over all pages. wbs_name_contains, code_type / code_value / include_child_codes and fields= as in p6_query_activities. Order: start, finish, Activity ID.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | Rows per page (max 200). | |
| weeks | No | ||
| fields | No | ||
| offset | No | Rows to skip: pass next_offset from the previous page. | |
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| code_type | No | ||
| from_date | No | ||
| code_value | No | ||
| include_completed | No | ||
| wbs_name_contains | No | ||
| include_child_codes | No | ||
| include_in_progress | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds real behavioral detail: half-open window [from, to), how open activities use remaining/early dates, exclusion of LOE and WBS summary activities, and deterministic ordering. It omits pagination limits and rate/performance caveats, keeping it short of a 5.
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?
It is information-dense with little filler, but delivered as one run-on paragraph mixing return-shape, window math, inclusion rules, and parameter reuse. Front-loading the output keys is helpful; the lack of sentence-level structure makes it harder to scan than it needs to be.
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?
With no output schema, the description fully documents the return shape (total, offset, returned, next_offset, rows, window, data_date, counts, schedule_state, note) and the pagination contract (pass next_offset). Combined with window and filtering semantics, an agent has everything needed for correct, paginated 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?
Schema coverage is only 23% across 13 parameters, so the description carries the burden — and it largely does, explaining from_date time semantics, days/weeks window length, include_in_progress/include_completed filtering effects, wbs_name_contains, the code_* family, fields, and offset (via next_offset). limit and a few optionals are left to the schema, so it compensates well but not completely.
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?
It states a specific operation (a look-ahead window of a project) and precisely enumerates which activities are listed and under what window semantics, which goes well beyond restating the name. It differentiates scope from a general activity query by defining the half-open window and inclusion rules, though it never explicitly contrasts itself with p6_query_activities.
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?
Usage context is implied rather than stated: defaults (days=14, include_in_progress, include_completed) and the from_date/data-date fallback are given, but there is no explicit 'use this when / use p6_query_activities instead' routing. The reference to p6_query_activities for shared params hints at the sibling relationship without clarifying when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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), 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; finish variance in calendar days, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| baseline | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the baseline fallback rule ('baseline= else the project baseline'), the 0.01-point mismatch threshold, and how spi_units and percent_complete are computed. It does not cover error cases (e.g. unknown project ID), which keeps it from a 5.
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?
Front-loaded with the core purpose, but the rest is one enormous run-on sentence with deeply nested parentheses, making it hard to scan. Given there is no output schema the length is defensible, but the structure could be far cleaner (e.g. sectioned bullets).
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?
With no output schema, this dense enumeration of return sections is exactly the gap the description should fill, and it does so fairly thoroughly. Annotations cover the safety profile. Remaining gaps are failure behavior and any output-format/pagination notes, which limits it to a 4.
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 only 50%: 'project' is documented but 'baseline' has no schema description. The description compensates by explaining the baseline selection rule — the explicit baseline is used, otherwise the project baseline — which gives the optional parameter real meaning. It adds nothing for 'project' beyond the schema, so not a 5.
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?
States a specific verb+resource — 'One-call overview of a project' — and then enumerates the exact payload sections (dates, activities, relationships, critical, percent_complete, baseline, counts, schedule_state). It partially differentiates from siblings by noting that detail lives in p6_critical_path, p6_list_wbs and p6_progress_curve, but it never states a clean one-line boundary against those 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?
Usage is only implied: the 'one-call overview' framing suggests use when a broad snapshot is needed, and sibling references hint where to go for detail, but there is no explicit when-to-use/when-not statement. The mentions of p6_progress_curve and p6_list_wbs are data-equivalence notes rather than routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search activities, one page: {total, offset, returned, next_offset, rows}, ordered by start (actual, else early) then Activity ID. status: TK_NotStart, TK_Active or TK_Complete. Dates as YYYY-MM-DD (finish_before includes that day). wbs_name_contains matches the name of the activity's own WBS node only, not its parents: for a whole branch use p6_list_wbs, or an activity code filter. Durations and float in days of each activity's calendar. code_type (activity code type name, e.g. 'Discipline'; the project's own type wins over an EPS or global one) keeps activities with a code of that type; code_value narrows it to a code by path ('CON.MEC'), short name ('MEC': every match) or name, with its child codes unless include_child_codes=False; code_filter tells what was matched. fields= keeps task_code plus the fields named, e.g. ['task_name', 'early_start_date', 'early_end_date', 'total_float_d'], for smaller pages.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per page (max 200). | |
| fields | No | ||
| offset | No | Rows to skip: pass next_offset from the previous page. | |
| status | No | ||
| project | Yes | Project ID as shown in P6 (p6_list_projects). | |
| code_type | No | ||
| code_value | No | ||
| code_prefix | No | ||
| start_after | No | ||
| finish_before | No | ||
| name_contains | No | ||
| wbs_name_contains | No | ||
| include_child_codes | No | ||
| max_total_float_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent read, so the safety profile is covered. The description adds meaningful behavior beyond that: sort order with the 'actual, else early' start tiebreak, inclusive-date semantics for finish_before, and the fact that durations/float are expressed in each activity's own calendar days. It does not discuss paging cost or filter-combination behavior, so 4 rather than 5.
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?
No filler sentences and the page shape plus sort order are front-loaded, which is the right ordering for a search tool. The prose is dense and slightly run-on in the code_value/code_type stretch, but every clause adds operative 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?
With no output schema, the description properly documents the return envelope {total, offset, returned, next_offset, rows} and how to page via offset. Combined with the filter semantics, an agent has enough to call it correctly, though the three undocumented filter params and the unspecified param interactions leave a small gap.
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 only 21% across 14 params, so the description carries most of the burden and largely does: it explains status enum values, date format and inclusivity, the WBS scoping caveat, code_type precedence (project type beats EPS/global), code_value path/short-name/name resolution, include_child_codes, code_filter output, and fields= semantics. It leaves code_prefix, name_contains, and max_total_float_days entirely unexplained, which keeps it off a 5.
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?
States a specific verb+resource ('Search activities') and immediately defines the return envelope and sort order. It also differentiates itself from siblings by name, pointing at p6_list_wbs for whole-WBS-branch filtering and contrasting with p6_get_activity's single-activity scope.
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?
Gives a concrete routing rule: wbs_name_contains only matches the activity's own WBS node, so for a branch use p6_list_wbs or an activity-code filter. It also explains when to reach for code_type/code_value vs name filters. It stops short of explicit when-not guidance against p6_get_activity or p6_lookahead, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0p6_critical_pathp6_diagnosep6_float_analysisp6_get_activityp6_get_relationshipsp6_health_checkp6_list_projectsp6_list_wbsp6_lookaheadp6_project_summaryp6_query_activitiesScored across 11 tools
Each tool targets a distinct resource or analytical view, with clear boundaries between overlapping activity-oriented tools like p6_query_activities, p6_critical_path, p6_float_analysis, and p6_lookahead. Descriptions explicitly state when to use each tool.
All tools share the p6_ prefix and snake_case, with mostly verb_noun forms (list_projects, get_activity, query_activities). Minor deviation: several analysis tools are noun phrases (critical_path, health_check, lookahead, project_summary, float_analysis) and diagnose lacks a noun.
11 tools for a complex P6 scheduling and analysis domain is well-scoped, with each tool earning its place without redundancy. The count sits comfortably in the ideal 3-15 range.
The read-only analysis surface is strong, covering projects, WBS, activities, relationships, critical path, health checks, lookahead, project summary, and float analysis. Minor gaps remain: no direct resource/calendar/baseline enumeration and no write operations, though the server may intentionally be read-only.
AI-powered project controls tools for Primavera P6 and Primavera Unifier.
Forensic scheduling MCP for Primavera P6 (XER): AACE windows, DCMA-14, Monte Carlo, TIA.
Month-end billing for consulting, architecture and engineering firms: your AI assistant previews each invoice from approved time, retainers and progress billing, then drafts them for your review. Also reports utilization, project profitability, WIP and cash flow.
Build Gantt charts from your AI chat: tasks, dependencies, timeline spreadsheets. All data is local.
