Onplana

update_project

DestructiveIdempotent

Partially update one project: name, description, status (PLANNING/ACTIVE/ON_HOLD/COMPLETED/CANCELLED), startDate, endDate, budget (number or null), color, retainedLogic (true: the remaining work of a started task waits on its links, so a late predecessor pushes it; false: a started task holds). Only supplied fields change. Caller must have project.edit on the project. Project progress is not writable here: it is derived from the progress of the tasks underneath, so it changes through update_task rather than through this tool.

Input Schema

Name	Required	Description
`name`	No	2-255 chars.
`color`	No
`budget`	No
`status`	No
`endDate`	No	ISO date - must be after startDate when both set.
`feeAmount`	No	FIXED_FEE / MILESTONE: the sold fee, distinct from budget (the cost plan).
`projectId`	Yes
`startDate`	No	ISO date.
`statusDate`	No	ISO date the schedule is reported "as of" (MS Project Status Date, P6 Data Date). null clears, meaning today.
`description`	No
`billingModel`	No	How the project bills: TIME_AND_MATERIALS (hours x rate), FIXED_FEE (feeAmount recognised by approved-hours share of estimatedHours, capped), RETAINER (retainerAmount per retainerPeriod, over-servicing above retainerIncludedHours), MILESTONE (milestoneSchedule amounts recognised as linked milestones complete). Changing it clears the other models' terms.
`retainedLogic`	No	How a started task meets its links. true (retained logic): its remaining work waits on its incoming links, so a late predecessor pushes it. false (the default): it holds at its actual start. Takes effect on the next reschedule, and only while the server switch retained_logic_enabled is on.
`estimatedHours`	No	FIXED_FEE: hours the fee was priced on.
`retainerAmount`	No	RETAINER: fee per period.
`retainerPeriod`	No
`milestoneSchedule`	No	MILESTONE: [{ label, amount, milestoneId? }], each milestone linked at most once.
`retainerIncludedHours`	No	RETAINER: hours the fee covers per period.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / retainedLogic

Added value: +{
+  "description": "How a started task meets its links. true (retained logic): its remaining work waits on its incoming links, so a late predecessor pushes it. false (the default): it holds at its actual start. Takes effect on the next reschedule, and only while the server switch retained_logic_enabled is on.",
+  "type": "boolean"
+}

Changed9 schema fields changedOct 19, 2026

addedInput schema / properties / billingModel

Added value: +{
+  "description": "How the project bills: TIME_AND_MATERIALS (hours x rate), FIXED_FEE (feeAmount recognised by approved-hours share of estimatedHours, capped), RETAINER (retainerAmount per retainerPeriod, over-servicing above retainerIncludedHours), MILESTONE (milestoneSchedule amounts recognised as linked milestones complete). Changing it clears the other models' terms.",
+  "enum": [
+    "TIME_AND_MATERIALS",
+    "FIXED_FEE",
+    "RETAINER",
+    "MILESTONE"
+  ],
+  "type": "string"
+}

addedInput schema / properties / estimatedHours

Added value: +{
+  "description": "FIXED_FEE: hours the fee was priced on.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedInput schema / properties / feeAmount

Added value: +{
+  "description": "FIXED_FEE / MILESTONE: the sold fee, distinct from budget (the cost plan).",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedInput schema / properties / milestoneSchedule

Added value: +{
+  "description": "MILESTONE: [{ label, amount, milestoneId? }], each milestone linked at most once.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "amount": {
+        "type": "number"
+      },
+      "label": {
+        "type": "string"
+      },
+      "milestoneId": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "label",
+      "amount"
+    ],
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

removedInput schema / properties / progress

Removed value: -{
-  "description": "Integer 0-100.",
-  "type": "number"
-}

addedInput schema / properties / retainerAmount

Added value: +{
+  "description": "RETAINER: fee per period.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedInput schema / properties / retainerIncludedHours

Added value: +{
+  "description": "RETAINER: hours the fee covers per period.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedInput schema / properties / retainerPeriod

Added value: +{
+  "enum": [
+    "WEEK",
+    "MONTH",
+    "QUARTER",
+    null
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / statusDate

Added value: +{
+  "description": "ISO date the schedule is reported \"as of\" (MS Project Status Date, P6 Data Date). null clears, meaning today.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

AddedJun 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Goes beyond the annotations by disclosing the authorization requirement ('Caller must have project.edit on the project') and clarifying that the operation is a merge-style partial update rather than a full overwrite, which softens the destructiveHint=true annotation. It doesn't warn that changing status to COMPLETED/CANCELLED or changing billingModel clears other models' terms is irreversible, though that detail lives in the schema.

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?

A single dense paragraph, front-loaded with the verb and field list, with the permission and progress-exclusion constraints appended. Most sentences earn their place, though the retainedLogic explanation is the longest clause and largely repeats the schema.

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 17-parameter mutation tool with no output schema, the description covers identity, partial-update semantics, authorization, and the most common non-obvious pitfall (progress is derived). Remaining gaps are the billing-model parameters and their side effects, which are documented in the schema but not signposted in the description.

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?

The description restates the status enum verbatim from the schema and re-explains retainedLogic, which the schema already documents in more depth (including the retained_logic_enabled server switch). It omits the eight billing-related parameters (feeAmount, billingModel, estimatedHours, retainer*, milestoneSchedule) and statusDate, so with 65% schema coverage it neither duplicates nor compensates fully — baseline 3.

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

Purpose5/5

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

States a specific verb, resource and semantics ('Partially update one project') and enumerates the writable field surface (name, description, status, dates, budget, color, retainedLogic). It also explicitly bounds scope by naming what is NOT writable (progress) and routing that to update_task, which distinguishes it from the many sibling update_* tools.

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 a clear positive context ('Only supplied fields change' → use for partial edits) and an explicit exclusion plus alternative: progress is derived and 'changes through update_task rather than through this tool'. It does not cover adjacent cases such as billing-model switching side effects or when to prefer this over update_portfolio/update_milestone, so it falls short of a full when/when-not map.

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

All Onplana tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

update_project

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources