Skip to main content
Glama
Sign In
P6 MCP

P6 MCP

by nizarhamza
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

p6_list_projects

Read-onlyIdempotent

Lists Primavera P6 projects with pagination, optional EPS filtering, ordering, template exclusion, and baseline inclusion so you can browse or select projects for analysis.

Instructions

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), baseline_of, and the EPS node holding it: eps_id, eps_name, eps_path (EPS names from the top, joined with ' > '); all three None for a project outside every EPS node. EPS nodes are never listed; baselines only with include_baselines=True (baseline_of is set); exclude_templates=True leaves out the P6 template projects (status WS_Template, or no EPS node). eps= an EPS ID: the projects of that EPS node and of every EPS below it. order: 'project' (Project ID) or 'eps' (EPS tree order as p6_list_eps order='tree', then Project ID; projects outside every EPS node last).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "p6_list_projects"
  }
}

Input Schema

NameRequiredDescriptionDefault
epsNo
limitNoRows per page (max 200).
orderNoproject
offsetNoRows to skip: pass next_offset from the previous page.
exclude_templatesNo
include_baselinesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.0.0
    • addedInput schema / properties / eps
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Eps"
+}
    • addedInput schema / properties / exclude_templates
      Added value: +{
+  "default": false,
+  "title": "Exclude Templates",
+  "type": "boolean"
+}
    • addedInput schema / properties / order
      Added value: +{
+  "default": "project",
+  "enum": [
+    "project",
+    "eps"
+  ],
+  "title": "Order",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, and the description adds substantial behavior the annotations cannot convey: the pagination contract with next_offset, the exact template-project definition (status WS_Template or no EPS node), and the null-handling rule for projects outside every EPS node. These are the details that prevent wrong calls and misinterpreted results.

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?

It is front-loaded with the response envelope before the field list and parameters, and nearly every clause adds information. It is a dense, run-on block with heavy parenthetical nesting that would scan better as short bullets, but there is little wasted text.

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

Completeness5/5

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

With no output schema, the description takes on the return-shape burden and does so explicitly, down to the page envelope and every row field including the three EPS columns. All six parameters are accounted for, so an agent has everything needed to call it and interpret the result.

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?

Schema description coverage is only 33% (limit and offset only), so the description must carry eps, order, exclude_templates and include_baselines — and it does, including what 'eps' recurses into and what 'order=eps' means (EPS tree order as p6_list_eps order='tree', then Project ID, projects outside EPS last). This fully compensates for the schema gap.

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?

The description opens by naming the resource and the exact return envelope ('Projects, one page: {total, offset, returned, next_offset, rows}') and enumerates the row fields, so an agent knows precisely what it gets. It also differentiates itself from p6_list_eps by stating 'EPS nodes are never listed'. The verb is only implied by the tool name rather than stated, which keeps it just 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.

Usage Guidelines4/5

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

It gives concrete conditions for each optional filter: 'eps= an EPS ID: the projects of that EPS node and of every EPS below it', 'baselines only with include_baselines=True', 'exclude_templates=True leaves out the P6 template projects'. It does not state when to reach for this tool over p6_project_summary or p6_query_activities, so alternative-selection guidance is incomplete.

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