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/<region>/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_edit_message, teams_delete_message, teams_react, marking read, renaming a group chat or adding and removing its members (teams_rename_chat, teams_add_chat_members, teams_remove_chat_members), and starting a new one (teams_create_group_chat) — 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, meeting recaps) declare the same scope: the three domains teams.cloud.microsoft, sharepoint.com and substrate.office.com, plus the chat-service, search and meeting-recap captures and one capture per SharePoint host the server has already captured from (usually just your own OneDrive host — see SharePoint file download). 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. Upgrading to the release that added teams_get_meeting_recap asks once more, because the recap capture (teams.cloud.microsoft/api/mcps/*) is new to that scope.

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

... View full README on GitHub