How to give an AI agent access to Google Calendar and Outlook with MCP

What an agent needs from a calendar

The Model Context Protocol lets an AI client call tools on a server. For calendars, the server holds an OAuth grant from one user and turns tool calls into calendar API calls: list events, create one, answer an invitation, find a free time.

The access is per user. The agent reads and writes one person's calendar with that person's permission, the same delegated OAuth grant a calendar app uses. Microsoft's Work IQ states it directly: "Requests run in the context of the signed-in user" and "Application-only authentication isn't supported."

So every option below comes down to the same questions. Whose OAuth client do the users approve, who keeps their tokens, and what happens when a token stops working.

Google's Calendar MCP server

Google runs its own server at https://calendarmcp.googleapis.com/mcp/v1, over Streamable HTTP. It is "available as part of the Google Workspace Developer Preview Program", not generally released.

To use it you need:

1. Membership in the Developer Preview Program.
2. Your own Google Cloud project, with the Google Calendar API (calendar-json.googleapis.com) and the Google Calendar MCP API (calendarmcp.googleapis.com) enabled.
3. Your own OAuth client of type Web application, with "Use this client for an AI-powered agent" checked.
4. A consent screen. Google suggests the Internal user type where available; otherwise External, with test users added.

The tools are create_event, delete_event, get_event, list_calendars, list_events, respond_to_event, suggest_time and update_event. The page's navigation also lists search_events.

Two things the page leaves open. It lists three read-only scopes (calendar.calendarlist.readonly, calendar.events.freebusy, calendar.events.readonly) while offering write tools, and it doesn't say which scopes those need. It also says nothing about consumer Gmail accounts or when the server leaves preview.

An External app in testing has Google's usual limits: up to 100 test users, and "authorizations by a test user will expire seven days from the time of consent".

The November 11, 2026 rule

Google's release notes of October 12, 2026 say: "Starting November 11, 2026, Google Workspace MCP servers will reject requests" from OAuth clients not marked as agentic, and "OAuth clients that are not marked as agentic by November 12, 2026 will remain non-agentic." After that date, using MCP means creating a new client with the agent box checked.

The same note says that apps that are not AI agents, "like those that only call Google Workspace REST APIs, are not affected" by the change.

If one product has both a regular calendar feature and an agent, Google wants two clients. Google Cloud's help: "you must create and maintain separate OAuth 2.0 client IDs for each workflow."

Service accounts with domain-wide delegation can't be marked as agents, because "service accounts aren't managed in Google Auth Platform > Clients". Google says their requests aren't rejected for that reason; the Workspace administrator's delegation settings control them.

Open-source MCP servers

Most people connect an agent to Google Calendar through a community server. Each one runs on your own Google Cloud project. Stars as of October 28, 2026:

The setup cost is the same Google work any calendar app has. You create the project, configure the consent screen, add yourself as a test user, and live with the testing limits. The nspady README warns: "While an app is in test mode the auth tokens will expire after 1 week." Removing that limit for other users means Google's OAuth verification.

taylorwilsdon's server says "this server only calls Google's REST APIs." By Google's wording, that puts it outside the November 11 rule, which applies to Google's own MCP servers.

The Softeria README carries a warning about personal Microsoft accounts: "as of June 2026, refresh tokens issued via the default 'common' authority are rejected at the first refresh," and it tells those users to set the tenant to consumers. That is the project's report, not something we found in Microsoft's documentation.

These servers are built for one person running an agent on their own machine. A product that gives agents to many users needs each user's tokens stored server-side, refreshed, and reconnected when they break.

Microsoft's Work IQ MCP

Microsoft's answer is Work IQ MCP, which "is generally available as part of the Work IQ API". It has a small set of generic tools that act on resource paths, for example create_entity /me/events to create a calendar event.

• Sign-in is Microsoft Entra ID, delegated only.
• Billing is usage-based, in Copilot Credits.
• The older per-workload servers, Calendar (preview) among them, "are only intended for backward compatibility purposes and shouldn't be used in production environments or new projects."

Work IQ is built for Microsoft 365 organizations. We found nothing on personal Outlook.com accounts. In work accounts, Microsoft's default consent policy keeps users from consenting to Calendars.Read and Calendars.ReadWrite, so expect an administrator's approval for any calendar agent.

Mark tools as reading or changing data

An agent that can delete events needs a client that asks before it does. MCP has tool annotations for this:

The defaults assume the worst: a tool with no annotations counts as changing data and possibly destructive. A calendar server should mark its tools.

[
  { "name": "list_events",  "annotations": { "readOnlyHint": true } },
  { "name": "create_event", "annotations": { "readOnlyHint": false, "destructiveHint": false } },
  { "name": "delete_event", "annotations": { "readOnlyHint": false, "destructiveHint": true, "idempotentHint": true } }
]

They are hints, not guarantees. The spec: "Clients should never make tool use decisions based on ToolAnnotations received from untrusted servers."

How Pyas handles it

Pyas has an MCP server, the npm package @pyas/mcp. In Claude Code:

claude mcp add pyas --env PYAS_API_KEY=pyas_sk_test_... -- npx -y @pyas/mcp

Its tools include list_events, create_event, find_meeting_times, get_free_busy, respond_to_event and accounts_needing_attention, across Google Calendar and Outlook. Each tool is marked as reading, changing or deleting data, and --read-only offers only the tools that change nothing. Test keys (pyas_sk_test_...) reach only your app's sandbox of sample calendars. Pyas runs no AI models; your agent brings its own.

With Pyas Auth, users approve Pyas on Google's, Microsoft's and Zoom's own consent screens, so there is no Cloud project to set up and no 7-day testing tokens. Microsoft's default consent policy can still require an administrator to approve calendar access for work accounts, with Pyas Auth too. Pyas stores and refreshes the tokens, and the connection.broken webhook fires when a user's connection stops working.

Pyas calls Google Calendar's REST API, not Google's MCP servers. That is the case Google's October 12 note describes as not affected by the agentic rule. It is Google's carve-out for REST integrations as written today, not a promise about future rules.

Common questions

Do I need Google's Calendar MCP server to give an agent calendar access?

No. Any MCP server that calls the Calendar REST API works. Google's server is one option, in developer preview, and the only kind the November 11 rule covers.

What happens to my existing OAuth client on November 11, 2026?

If it calls Google's Workspace MCP servers and isn't marked as an AI agent, Google rejects those requests. Clients not marked by November 12 stay non-agentic, so you create a new one.

Why does my agent lose Google Calendar access every week?

The OAuth app is in testing. Google expires test users' authorizations seven days after consent. Moving the app to production ends the weekly expiry, but until Google verifies it, users see the unverified app warning and the app is capped at 100 new users.

Can a client trust readOnlyHint?

Only from a server it trusts. Annotations are hints from the server, and the spec tells clients not to base decisions on them when the server is untrusted.