Summary
The calendar-UpdateEvent MCP tool does not expose categories as a parameter, even though Microsoft Graph's PATCH /me/events/{id} fully supports writing categories and the Work IQ MCP already has a working OAuth client with Calendars.ReadWrite (the same client successfully reads categories today via ListCalendarView).
This blocks any "categorize my meetings" automation. There is no MCP path to write categories programmatically — every fallback we tried hit a tenant-policy wall.
Reproduce
- Call
calendar-UpdateEvent with any combination of supported parameters.
- There is no
categories parameter in the schema.
- Even when
categories is passed inline (in case the wrapper forwards unknown fields), it is dropped silently — no error surface.
Why fallback paths don't work for Microsoft corp tenant users
Trying to bypass the wrapper and hit Graph directly is blocked at every layer for users on the microsoft.com tenant:
| Path |
Result |
| Azure CLI Graph token |
Lacks Calendars.ReadWrite (1P preauth list locked) |
| Microsoft Graph CLI device-code flow |
Blocked by Conditional Access token-protection policy (AAD error 53003) |
| Microsoft Graph CLI interactive flow |
Blocked by tenant "admin consent required" policy |
| Microsoft Office client interactive |
Same admin-consent wall |
| Office client + MSAL broker (pymsalruntime) |
Redirect URI not registered for that client |
| Outlook for Mac AppleScript |
Stripped from scripting dictionary in v16.109+ |
The only realistic unblock is exposing categories directly in the MCP, since the MCP already has the right OAuth client with the right scope.
Requested change
Add an optional categories parameter (array of strings) to:
calendar-UpdateEvent
- (parity)
microsoft-outlook-calendar-UpdateEvent if separate
Behavior matches Graph: categories is the full list, replacing the existing array. Callers that want to preserve existing categories should GET first, merge, and PATCH. (Or expose categoriesToAdd / categoriesToRemove for additive semantics — either works.)
Code change scope
Wrapper-only change. The underlying Graph endpoint and required permission (Calendars.ReadWrite) are already covered by the MCP's existing OAuth client. No new consent, no new scope, no new auth flow.
Use cases unblocked
- 8-category taxonomy auto-tagging (Will's
calendar-categorize skill)
- Project-call labeling for ADO weekly reports
- Deep-focus auto-tagging
- Shiproom-prep sweeps
- Any plugin that wants to apply categories programmatically
mail-UpdateMessage already exposes categories; calendar parity is a reasonable expectation.
Workaround in place today
Manual right-click in Outlook. Defeats the automation.
Summary
The
calendar-UpdateEventMCP tool does not exposecategoriesas a parameter, even though Microsoft Graph'sPATCH /me/events/{id}fully supports writingcategoriesand the Work IQ MCP already has a working OAuth client withCalendars.ReadWrite(the same client successfully readscategoriestoday viaListCalendarView).This blocks any "categorize my meetings" automation. There is no MCP path to write categories programmatically — every fallback we tried hit a tenant-policy wall.
Reproduce
calendar-UpdateEventwith any combination of supported parameters.categoriesparameter in the schema.categoriesis passed inline (in case the wrapper forwards unknown fields), it is dropped silently — no error surface.Why fallback paths don't work for Microsoft corp tenant users
Trying to bypass the wrapper and hit Graph directly is blocked at every layer for users on the
microsoft.comtenant:Calendars.ReadWrite(1P preauth list locked)The only realistic unblock is exposing
categoriesdirectly in the MCP, since the MCP already has the right OAuth client with the right scope.Requested change
Add an optional
categoriesparameter (array of strings) to:calendar-UpdateEventmicrosoft-outlook-calendar-UpdateEventif separateBehavior matches Graph:
categoriesis the full list, replacing the existing array. Callers that want to preserve existing categories shouldGETfirst, merge, andPATCH. (Or exposecategoriesToAdd/categoriesToRemovefor additive semantics — either works.)Code change scope
Wrapper-only change. The underlying Graph endpoint and required permission (
Calendars.ReadWrite) are already covered by the MCP's existing OAuth client. No new consent, no new scope, no new auth flow.Use cases unblocked
calendar-categorizeskill)mail-UpdateMessagealready exposescategories; calendar parity is a reasonable expectation.Workaround in place today
Manual right-click in Outlook. Defeats the automation.