Microsoft Teams MCP

microsoft-teams-mcp

MCP server for Microsoft Teams — list every chat and channel you are in, read any of them by id or name, pull everything you have not read yet, read your Activity feed, fetch inline images, and — each one confirmed by you first — post messages and reactions, using your signed-in browser session.

This project was developed and is maintained by AI (Claude Code). Use at your

own discretion.

How it works

Chats and channels are read through Teams' own chat-service REST API (https://teams.cloud.microsoft/api/chatsvc/ /v1). The server needs a bearer token for it, and the only place one exists is your signed-in teams.cloud.microsoft tab: through the fetchproxy browser bridge it captures the Authorization header off a request the Teams web app makes to its chat service — once. From then on every call is a plain server-side request; the token is cached in ~/.microsoft-teams-mcp/token.json for its ~23h lifetime (so a restart needs no browser), and a 401 re-captures once and replays. teams.microsoft.com (the old host) is not supported.

So chats and channels no longer need to be open in the browser — any of them can be read by id or name, and listing covers every chat, not just the ones the sidebar shows. To capture a token, an idle tab is not enough: click into any chat so Teams calls its chat service.

The Activity feed comes from the same API. It is a chat-service conversation of its own (48:notifications), so teams_list_activity reads it like any chat — no Activity view (or any view) needs to be open, and nothing reads the page. The bridge is used for one thing only: capturing the token.

By default nothing here marks anything read. Reading a chat through this server leaves your Teams unread badges exactly as they were — unless you ask for it: teams_mark_read, or mark_read: true on teams_list_messages / teams_list_unread_messages, moves your read marker forward. The writes — teams_send_message, teams_react and marking read — go through the same chat-service API and change nothing until you confirm (see Writes).

Pairing

The bridge remembers a pairing only for the exact set of domains it approved, and approving a grant replaces the stored list of header captures. So all of this server's captures (chat service, SharePoint, Substrate search) declare the same scope: the three domains teams.cloud.microsoft, sharepoint.com and substrate.office.com, plus the chat-service and search captures and one capture per SharePoint host the server has already captured from. Each capture still reads only the one header it needs. The SharePoint hosts are remembered in ~/.microsoft-teams-mcp/bridge-scope.json (beside the SharePoint token cache; not written with TEAMS_TOKEN_CACHE=false) once a capture from them succeeds.

Up to 0.7, each capture declared only its own domain, so the bridge asked to pair again (or to update its grants) whenever the server moved between chats, search and files. Upgrading from 0.7 asks to pair once more, for the combined scope; after that it stays paired.

If you run the bridge in more than one browser or browser profile, each one is a different extension identity, and the server trusts only the one it paired with. Keep the bridge enabled in the browser you pair with (or re-pair deliberately with FETCHPROXY_TRUST_NEW_EXTENSION=1 after switching browsers).

SharePoint file download

A shared file in a chat or channel is not in Teams' own object store (where inline images live) — it is in SharePoint, which does not accept the chat-service token. So teams_get_attachment captures a separate SharePoint token and fetches the file through SharePoint's v2.1 shares API, then downloads the pre-signed link it returns (with no token attached).

Two things follow from that:

• One pairing covers it. Every capture this server makes — chat service, SharePoint and search — declares the same ContextMint Bridge scope: the domains teams.cloud.microsoft, sharepoint.com and substrate.office.com, and the same list of header captures. So approving microsoft-teams-mcp once covers all three, and moving between chats, files and search never asks again (see Pairing). The first file from a new SharePoint host asks once to grant that host's capture.
• Open the file once per SharePoint host. The SharePoint token is captured from the browser's own request to the file's SharePoint host, is short-lived (~53 minutes), and is scoped to one host family. So the first file from a given host in a session may need you to open it once in a signed-in Teams tab (that browser request is what the token is read from); after that the token is cached and refreshed until it expires. A file your account cannot open, or on a SharePoint host your token does not cover, comes back as metadata and its open link rather than failing.

Substrate search

teams_search_messages searches the way the Teams search box does: through Microsoft Substrate (POST https://substrate.office.com/searchservice/api/v2/query). Substrate does not accept the chat-service token either, so search captures a third token — off the request the Teams tab makes to substrate.office.com/searchservice/* when you run a search there — and caches it in ~/.microsoft-teams-mcp/substrate-token.json. As with the other two, it is read only from the request header, never from page storage.

• No separate pairing. Search is part of the one bridge scope every capture declares (see Pairing), so the pairing that reads chats covers it.
• Run a search in Teams once. The token is read off the Teams tab's own search request, so the first search may need you to type anything into the Teams search box and press Enter while the capture waits (TEAMS_CAPTURE_TIMEOUT, default 30s).
• It falls back to scanning. In the default mode: "auto", when no Substrate token can be captured or the search fails, the tool scans recent conversations instead (source: "scan", with a fallback_reason), and does not wait on another capture for 10 minutes. mode: "substrate" fails instead; mode: "scan" never touches Substrate.

• It does not re-capture in a loop. If a freshly captured token is still refused (401), the same 10-minute cooldown applies, so auto goes straight to the scan instead of waiting on the bridge every call.

Verified live 2026-10-12. A token captured off the Teams tab's own

search request (it lives about 1.4 hours) was replayed from Node against

read-only queries such as deploy. Confirmed: the request body (cvid, logicalId

and a scenario are required; the sort is `{ Field: "Time", SortDirection:

"Desc" }`), that no header beyond the bearer is needed, the response fields

(conversation in ClientThreadId, a channel root in ClientConversationId's

;messageid=, the message id in InternetMessageId, sender name and SMTP

address but no MRI, a plain-text Preview of at most ~255 characters, an

approximate Total), paging by from/size (up to 200), and that

conversation and since can be sent server-side as ClientThreadId:"…"

and an unquoted sent>=…. from stays client-side: Substrate's own from:

matches word prefixes, not "display name contains". A redacted response is

in tests/fixtures/substrate-query-response.json.

Install

npm i -g @chrischall/microsoft-teams-mcp

Requires the ContextMint Bridge browser extension and @fetchproxy/cli, on a matching major version. Install the bridge from its releases page: in Chrome, unzip the chrome zip and load it unpacked (chrome://extensions → Developer mode → Load unpacked). Safari isn't available yet (it will ship inside the ContextMint app, which has no public download), so use Chrome for now.

ContextMint Bridge is the fetchproxy browser extension under its new name, from the same maintainer — fetchproxy's own README (https://github.com/chrischall/fetchproxy#extension) points to it. Its source is public at https://github.com/nullnet-app/contextmint-bridge: build it yourself, or check a release zip against the .sha256 file published beside it (shasum -a 256 -c contextmint-bridge-chrome- .zip.sha256).

npm i -g @fetchproxy/cli

The first call prints a 6-digit pair code to approve in the ContextMint Bridge popup; the grant persists.

Install in opencode

opencode reads MCP servers from opencode.json (project) or ~/.config/opencode/opencode.json (global):

{

"mcp": { "servers": { "teams": { "type": "local", "command": ["npx", "-y", "@chrischall/microsoft-teams-mcp"] } } } }

Configuration

Everything is optional — by default the token is captured from your browser.

Tools

• teams_list_conversations — every chat you are in (1:1, group and meeting chats, not just the visible sidebar, plus your 48:notes self-chat as kind self when Teams lists it), favorites and pinned chats first, then most recent activity first: id, kind, title, unread hint, ISO-8601 last-activity time, last-message preview and sender. unread_only (exact — see belo