Planner Premium MCP
An MCP server for Microsoft Planner Premium - for the plans, dependencies and schedules that the Planner API in Microsoft Graph cannot reach.
A straight answer on where it stands, with no waiting-list theatre.
Who it is built for
Organisations that run their projects in Microsoft Planner Premium, with schedules and dependencies, and want their assistants to work with it instead of having people assemble status reports by hand.
The problem
Premium plans cannot be reached through the Planner API in Microsoft Graph. Microsoft states that Premium plans and tasks are not available there, and that its endpoints do not expose dependencies, resource assignments or custom fields. Every integration built on that API is therefore unable to see a Premium plan at all, including Microsoft's own Planner MCP Server, which supports basic plans. Writing directly to the Premium tables in Dataverse instead produces no error and no change.
Our approach
The server takes the supported route: Dataverse and the Project Schedule APIs, with the scheduling service performing the write. Changes are collected in a session and applied as one set. Before that, the server reports what will be applied and what will not, and why - so an assistant never reports success on work that did not happen.
Why Premium needs its own path
Premium plans are not a variation of basic plans. They are stored elsewhere and reached through a different API.
This is blindness, not a feature gap
Microsoft states that Premium plans and tasks are not available on the standard Planner API in Graph, and that its endpoints do not expose dependencies, resource assignments or custom fields. Microsoft's own Planner MCP Server says the same of itself: it supports basic plans, and premium capabilities such as dependencies, task history and custom fields are not yet available. Any server built on that API is therefore unable to see a Premium plan at all, rather than seeing it partially.
How a change is applied
The scheduling service performs the write, so changes are collected and applied as one set rather than written row by row.
Parts list
- 01Open a change sessionEffect: Scheduling entities cannot be written directly. The session is the supported route, and the one the scheduling engine will act on.
- 02Collect the changesEffect: Identifiers, parent and child ordering, dependency types and unit conversion are handled by the server rather than left to the assistant to construct.
- 03Check what the service acceptsEffect: Before anything is applied, the server reports what will be applied and what will not, and why. Some things are not writable through any API, and saying so is more useful than failing halfway.
- 04Apply the set in one goEffect: The set is applied together and the result is confirmed. Where the scheduling engine refuses part of it, the refused part is named instead of the whole batch failing.
A write that vanishes is worse than a write that fails
Writing to the Planner Premium tables in Dataverse directly produces no error and no change. For an assistant that is the worst possible outcome: it reports success on work that never happened. Everything above exists so that a refusal is visible, named, and returned before the change is attempted.
What it does
- 01Premium plans, dependencies, schedules and sprints that the Planner API in Graph does not expose
- 02Change sessions through the Project Schedule APIs, the only supported write path
- 03A preflight that names what cannot be applied, instead of dropping it silently
- 04Identifiers, ordering, dependency types and unit conversion are handled by the server
- 05Delegated sign-in: the assistant sees only what the signed-in person may see
Editions and terms are not settled yet
The product is in development. Editions, scope and terms will be set together with the first users. If you want to run it, talk to us before that is fixed.
Register as an early user