updatePlanPhase
Update a plan phase, or many phases in one call. Each phase has its own versionTimestamp (its updated_at in epoch milliseconds): listPlanPhases and getPlan (phases[].versionTimestamp) return it for every phase in a plan, getPlanPhase for one, and every write returns the new one. Never pass the pl...
This record as markdown: /tools/io-stablebaseline-sb/updateplanphase.md
What updatePlanPhase does on Stable Baseline
AI agents use updatePlanPhase to create or update resources in Stable Baseline, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Stable Baseline environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
name | string | — | |
color | string | null | — | Phase colour. Must be one of: #3b82f6 (Blue), #f59e0b (Amber), #8b5cf6 (Purple), #ec4899 (Pink), #06b6d4 (Cyan), #14b8a6 (Teal), #6366f1 (Indigo), #6b7280 (Grey |
items | array | — | Optional bulk form: update up to 200 phases in one call, each entry { phaseId, versionTimestamp, ...the fields to change } with the same fields as a single call |
fields | array | — | Optional. Answer with only these fields instead of the whole phase, for example ["id", "versionTimestamp"]. Any of the phase's own fields (snake_case or camelCa |
planId | string | — | Optional. Narrows a friendly-id lookup to one plan, given as the plan's UUID or friendly id (such as PLN-3). Phase ids are numbered per plan, so PHA-2 exists in |
status | string | — | Status: not_started, in_progress, completed, on_hold, cancelled. |
phaseId | string | — | Required unless you send items. The phase's UUID or friendly id (such as PHA-7); with a friendly id, give planId too, since PHA- ids repeat in every plan. |
end_date | string | null | — | YYYY-MM-DD on or after start_date, or null to clear. While date_mode is 'auto' and the phase has dated tasks, the tasks' range wins and the reply carries a note |
position | number | — | |
priority | string | — | Priority: low, medium, high, critical. |
wbs_code | string | — | |
date_mode | string | — | auto: the phase's dates follow its tasks (earliest task start to latest task end, kept current). manual: the dates you set are kept. Switching to auto recompute |
Parameters from the server's own tool schema.
Why updatePlanPhase is rated Medium
An AI agent can call updatePlanPhase faster than any human can review: one bad instruction and it creates or modifies resources in Stable Baseline by the hundred, each call as confident as the last.
Risk signalsHigh parameter count (28 properties) · Bulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs updatePlanPhase safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Stable Baseline, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For updatePlanPhase, this is the rule to start with:
updatePlanPhase stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Stable Baseline, apply this rule, and every updatePlanPhase call is checked against it from then on.
Questions about updatePlanPhase
Update a plan phase, or many phases in one call. Each phase has its own versionTimestamp (its updated_at in epoch milliseconds): listPlanPhases and getPlan (phases[].versionTimestamp) return it for every phase in a plan, getPlanPhase for one, and every write returns the new one. Never pass the plan's own top-level versionTimestamp. A phase with date_mode 'auto' (the default) takes its dates from its tasks; set date_mode 'manual' to pin dates by hand, or 'auto' to make them follow the tasks again. Pass fields (for example ["id", "versionTimestamp"]) for a short answer; a note saying the dates were replaced by the tasks' range always comes back. To change many phases, send items: up to 200 entries of { phaseId, versionTimestamp, ...changes } per call (more than 200: split them into several calls of up to 200), each checked and written on its own and answered with one row per entry plus a summary. It is categorised as a Write tool in the Stable Baseline MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
updatePlanPhase accepts 12 parameters: name, color, items, fields, planId, status, phaseId, end_date, position, priority, wbs_code, date_mode. The full parameter table on this page comes from the server's own tool schema.
Register the Stable Baseline MCP server in PolicyLayer and add a rule for updatePlanPhase: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Stable Baseline. Nothing to install.
updatePlanPhase is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the updatePlanPhase rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for updatePlanPhase. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
updatePlanPhase is provided by the Stable Baseline MCP server (https://api.stablebaseline.io/functions/v1/cloud-serve/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Stable Baseline, and thousands of servers like it.
This server
Across the catalogue