Ms Calendar Mcp

io.github.0xka13bPublished by GitHub account 0xka13bv1.0.1Updated Oct 24, 2026

Microsoft Calendar (Outlook Calendar) MCP server for managing events via Microsoft Graph.

Overview

AI-generated overview

A local MCP server that lets an assistant read and manage Microsoft Outlook calendar events through the Microsoft Graph API.

What you can do
List and read calendar events, including fetching a single event by ID and viewing calendar data through Microsoft Graph v1.0 wrappers. Create, update and delete calendar events, with mutating tools flagged as destructive for client confirmation. Sign in once with a Microsoft account and let the server refresh tokens silently for later sessions. Optionally run over Streamable HTTP with a per-request bearer token instead of stdio.
When to use it
Use it when you want an AI assistant to look up, schedule or change events in your own Microsoft 365 / Outlook calendar, for example drafting meeting changes or reviewing upcoming appointments from a desktop MCP client.
Requirements
Runs locally as a Node.js (>= 20) process, typically launched with npx. Needs a Microsoft Entra ID app registration (free) whose client ID is set in MICROSOFT_CLIENT_ID, delegated Calendars.ReadWrite and User.Read permissions, and a one-time login command that caches a refresh token. Optional variables include MICROSOFT_TENANT_ID, MICROSOFT_ACCESS_TOKEN, MICROSOFT_MCP_CACHE_DIR, MCP_TRANSPORT and PORT.
Before you install
The server acts on your behalf with read-write calendar access, so tools can create, modify and delete real events. It stores a refresh token on disk under the token cache directory, and MICROSOFT_ACCESS_TOKEN or an HTTP bearer token grants Graph access if exposed. Grant only the scopes you need and review mutating actions before confirming them.

Installation

In SourceWeft

  1. Open Ms Calendar Mcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

[Outlook]  [Calendar]  [OneDrive]  [SharePoint]  [Contacts]

Microsoft MCP

Model Context Protocol servers for Microsoft 365.
Calendar · Contacts · OneDrive · Outlook · SharePoint — on the official @modelcontextprotocol/sdk, over stdio or Streamable HTTP.

[CI] [coverage] [license: MIT] [node] [MCP SDK]

Each server speaks the real MCP protocol and runs over either transport:

  • stdio — for local MCP clients that launch the server as a subprocess (Claude Desktop, IDEs, the MCP Inspector).
  • Streamable HTTP — for remote/hosted use, with the Microsoft Graph access token supplied per request via Authorization: Bearer.

Servers

Servernpm package (and binary)Tools
[Image]Calendarms-calendar-mcp9
[Image]Contactsms-contacts-mcp7
[Image]OneDrivems-onedrive-mcp9
[Image]Outlookmicrosoft-outlook-mcp14
[Image]SharePointms-sharepoint-mcp23

All tools are thin wrappers over the Microsoft Graph v1.0 API.

Layout

microsoft-mcp/├── apps/                       # one MCP server per Microsoft 365 product│   ├── calendar/│   ├── contacts/│   ├── onedrive/│   ├── outlook/│   └── sharepoint/│       └── src/│           ├── tools.ts        # declarative tool definitions (schema + handler)│           └── index.ts        # run({ name, version }, tools)└── packages/                   # shared building blocks    ├── core/                   # MCP server bootstrap + dual transport (stdio / HTTP)    ├── graph/                  # Microsoft Graph HTTP client    ├── validation/             # id / path / query sanitizers    └── logger/                 # structured JSON logging (stderr-only — stdio-safe)

A server is just a list of tools handed to run():

ts
// apps/calendar/src/index.tsimport { run } from "@microsoft-mcp/core";import { tools } from "./tools.js";
void run({ name: "microsoft-calendar", version: "1.0.0", title: "Microsoft Calendar" }, tools);
ts
// a single tooldefineTool({  name: "get_event",  description: "Get a single calendar event by ID.",  inputSchema: { event_id: z.string().describe("Event ID") },  confirmationPolicy: "never",  handler: ({ graph }, { event_id }) => {    validateId(event_id, "event_id");    return graph.request("GET", `/me/events/${event_id}`);  },});

confirmationPolicy ("always" for mutating/destructive tools, "never" for read-only) is surfaced to clients as MCP readOnlyHint / destructiveHint annotations.

Requirements

  • Node.js >= 20
  • pnpm 10 (corepack enable)

Setup

bash
pnpm installpnpm build        # build all servers (turbo) -> apps/*/dist/index.jspnpm check-types  # typecheck everything

Tests & CI

bash
pnpm test            # run the vitest suite oncepnpm test:watch      # watch modepnpm test:coverage   # run with a v8 coverage report (-> coverage/)

Tests live next to the code as *.test.ts and run on TypeScript source directly (no build step). The shared packages/* are covered by unit and integration tests — including a full Streamable-HTTP round-trip against a live server — and CI enforces a coverage floor on them. Each apps/* server ships an invariant suite that locks its tool surface (unique snake_case names, valid schemas and confirmation policies).

Every push and pull request to master runs CI: typecheck → build → tests with coverage. The coverage badge is regenerated from the run.

Authentication

You sign in once with your Microsoft account; the server then caches a refresh token and acquires access tokens silently from then on — no pasting, no 1-hour expiry. Sign-in uses your own Microsoft Entra ID app registration (free) so the servers act on your behalf.

1. Register an Entra ID app (one time)

  1. Azure Portal → Microsoft Entra ID → App registrations → New registration. Name it anything; pick the Supported account types that fit (single-tenant, multi-tenant, and/or personal accounts).

  2. Authentication → Add a platform → Mobile and desktop applications → add redirect URI http://localhost, and set Allow public client flows to Yes (enables the --device-code fallback).

  3. API permissions → Add a permission → Microsoft Graph → Delegated permissions → add the scopes for the servers you use (then Grant admin consent if your tenant requires it):

    ServerDelegated scopes
    CalendarCalendars.ReadWrite
    ContactsContacts.ReadWrite
    OneDriveFiles.ReadWrite.All
    OutlookMail.ReadWrite, Mail.Send
    SharePointSites.ReadWrite.All

    All servers also use User.Read. (offline_access is requested automatically for refresh.)

  4. Copy the Application (client) ID.

2. Sign in (one time per machine)

Set MICROSOFT_CLIENT_ID, then run the server's login command. A browser opens; after you consent, the token is cached under ~/.config/microsoft-mcp/:

bash
export MICROSOFT_CLIENT_ID=<your-client-id>
npx -y ms-calendar-mcp login           # opens the browsernpx -y ms-calendar-mcp login --device-code   # headless: shows a code to enter

From then on the server refreshes tokens automatically. Use a non-default tenant with MICROSOFT_TENANT_ID (default common).

Advanced: supply your own token

To bypass the built-in flow, supply a pre-acquired Graph token directly:

  • stdio: set MICROSOFT_ACCESS_TOKEN (takes precedence over the cached sign-in). Good for quick tests — mint one with az account get-access-token --resource https://graph.microsoft.com --query accessToken -o tsv.
  • HTTP: send Authorization: Bearer <token> on each POST /mcp request. Each request is stateless with its own token, so callers never share credentials — this is the model for hosted/remote deployments, which handle their own auth.

Running

stdio (e.g. Claude Desktop)

Each server is published to npm and runnable with npx — no clone or build. Sign in once first (npx -y ms-calendar-mcp login, see Authentication), then:

jsonc
// claude_desktop_config.json{  "mcpServers": {    "microsoft-calendar": {      "command": "npx",      "args": ["-y", "ms-calendar-mcp"],      "env": { "MICROSOFT_CLIENT_ID": "<your-client-id>" }    }  }}

Or point at a local build instead of npm:

jsonc
{  "command": "node",  "args": ["/abs/path/microsoft-mcp/apps/calendar/dist/index.js"],  "env": { "MICROSOFT_CLIENT_ID": "<your-client-id>" }}

During development you can skip the build and run the TypeScript directly:

bash
MICROSOFT_ACCESS_TOKEN=<token> pnpm --filter ms-calendar-mcp dev

Streamable HTTP

bash
# build first, then:PORT=3000 node apps/calendar/dist/index.js --http# or, in dev:pnpm --filter ms-calendar-mcp dev -- --http --port 3000

The server exposes POST /mcp (the MCP endpoint) and GET /healthz. Point any Streamable-HTTP MCP client at http://localhost:3000/mcp with an Authorization: Bearer header.

Transport selection

Resolved in this order: --stdio / --http flag → MCP_TRANSPORT=stdio|http → default stdio. HTTP port: --port <n> → PORT → 3000.

Environment variables

VariableUsed byDescription
MICROSOFT_CLIENT_IDstdioEntra ID app (client) ID for sign-in. Required for the login flow.
MICROSOFT_TENANT_IDstdioTenant for sign-in: common (default), organizations, consumers, or a tenant ID.
MICROSOFT_ACCESS_TOKENstdioPre-acquired Graph token; overrides the cached sign-in when set.
MICROSOFT_MCP_CACHE_DIRstdioOverride the token-cache directory (default ~/.config/microsoft-mcp).
MCP_TRANSPORTbothstdio (default) or http.
PORThttpListen port (default 3000).
MCP_HTTP_BODY_LIMIThttpMax request body size (default 50mb) for base64 uploads.
MCP_DEBUGbothAny non-empty value enables debug logs (to stderr).

Source: README.md at commit 3791c27

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v1.0.1LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts