Onplana

move_project

DestructiveIdempotent

Move a whole project to a new start date, the way Microsoft Project's Move Project does. Every task without actual work moves by the difference between the old and the new project start, counted in working days on the project's working calendar, so durations, links and lags stay as they are and no date lands on a non-working day. Tasks with an actual start, any progress, or status Done stay where they are, as do tasks whose dates come from Microsoft Planner; tasks linked after them are rescheduled from their links. Dated constraints move with their task. Deadlines move only with moveDeadlines: true. The project start becomes start, and the project end (the target finish, project.endDate.to in the result) moves by the same working days, so this is also the tool that moves a plan's finish. The finish the plan actually reaches is finish.to: the latest task finish the project schedule computes after the move (finish.from before it). Tasks that stay can finish later than every task that moves; then finish.to is later than project.endDate.to, finish.held gives how many such tasks and the latest (drivingTaskId, drivingTaskTitle), and finishNote states it in one sentence. update_project's endDate changes only the target date and moves no task. dryRun: true returns the same counts (moving, staying and why, deadlinesMoving, constraintsMoving) and the finish, and writes nothing. Requires the project-level project.edit permission. A start equal to the current one returns changed: false and writes nothing. The result carries undo, the move that puts the plan back.

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": {
      "projectId": "<projectId>",
      "start": "<start>"
    },
    "name": "move_project"
  }
}

Input Schema

Name	Required	Description
`start`	Yes	The new project start, YYYY-MM-DD.
`projectId`	Yes	The project to move. Use list_projects to find project ids.
`moveDeadlines`	No	Move task deadlines by the same working days too. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Far beyond what annotations provide: it explains the working-day offset algorithm, which tasks are held and why, how linked and constrained tasks behave, that deadlines only move with moveDeadlines, permission requirements, the no-op behavior, and that the result carries an undo move. This is consistent with destructiveHint=true and idempotentHint=true rather than contradicting them.

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?

Front-loaded with the core action and the moved/stayed rules, and nearly every sentence carries distinct information. It is dense and some sentences (the finish.to / project.endDate.to distinction, the held-task clause) are tangled enough to require a second read, which keeps it from a 5.

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?

There is no output schema, and the description compensates fully by describing the result fields (changed, moving/staying counts, deadlinesMoving, constraintsMoving, finish.from/finish.to, project.endDate.to, finish.held with drivingTaskId, finishNote, undo). For a destructive, multi-effect bulk mutation, an agent has everything needed to call it and interpret the response.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: moveDeadlines is only meaningful when true and governs deadline shifting, start is interpreted as the new project start driving the working-day delta, and projectId's scope is confirmed as the whole plan. The added semantics are concrete rather than a restatement.

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 and resource ('Move a whole project to a new start date') with the exact rescheduling semantics, and explicitly distinguishes itself from update_project ('update_project's endDate changes only the target date and moves no task'). An agent can choose between move_project, move_task and update_project without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Gives explicit when-to-use (also the tool that moves a plan's finish), when-not (tasks with actual work, progress, Done, or Planner-sourced dates stay put), the alternative (update_project for target-date-only changes), a safe trial path (dryRun: true writes nothing), and a prerequisite (project.edit permission). The no-op case (start equals current start returns changed: false) is also spelled out.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.