Enterprise AI · Microsoft 365
Publishing to Teams from any assistant
One MCP server written in .NET that takes a document drafted in Claude, ChatGPT or an M365 Copilot agent and publishes it straight into the right Teams channel or chat — over Microsoft Graph, as the signed-in user.
Role
Software Engineer
Period
2026
Source
Client-confidential
01 — Context
People draft real work inside assistants now — status reports, summaries, specs, meeting notes. Then they copy it out by hand, find the right channel, paste it, and fix the formatting. The thinking happens in one place and the work lives in another.
Closing that gap for one assistant is a plugin. Closing it for three is where it gets interesting, because every assistant has its own integration format — and because publishing is a write. A tool that reads the wrong record is an annoyance; a tool that posts to the wrong channel, or as the wrong identity, is an incident everybody can see.
02 — Architecture
MCP is the only integration contract. The server is plain .NET: it owns the tool definitions, the Entra ID token exchange, and the Microsoft Graph calls that resolve destinations and post content. Every assistant above it is interchangeable.
Clients
M365 Copilot
declarative agent
Claude
same server
ChatGPT
same server
Teams app
Next.js tab
MCP server · .NET
Tool contract
Entra ID · on-behalf-of
Destination resolver
Graph publisher
Microsoft 365
Microsoft Graph
teams, channels, chats
Teams channels
posts as the user
Teams chats
1:1 and group
Four clients, one contract — documents post as the signed-in user, to destinations that user can already reach.
03 — Decisions & trade-offs
MCP as the integration contract, not a per-assistant plugin
One server, four consumers. Cost: tools must be designed to the lowest common denominator across clients, and MCP is young enough that the spec still moves. Benefit: Claude and ChatGPT each came online in under a day after Copilot — configuration, not a second integration. When the assistant market shifts again, the publishing layer survives it.
On-behalf-of identity, never a service account
The signed-in user’s token is exchanged and every Graph call is made as them. Cost: three clients with three different identity models is the hardest plumbing in the build. Benefit: posts appear from the person who asked rather than from a bot, and they can only publish where they already have access — so channel permissions need no second implementation inside the AI layer.
Resolving destinations as a separate tool from publishing
The model lists and resolves a channel or chat first, then publishes to a resolved id. Cost: two round trips for what feels like one action. Benefit: the model cannot invent a destination — it can only publish to something Graph handed back, which is the difference between a wrong post and no post.
04 — Impact
12 tools
Across destinations, publishing and formatting
3 clients
Copilot, Claude and ChatGPT on one server
< 1 day
To bring each client after the first online
Building this on the Microsoft stack?
The .NET side of MCP is still thinly documented, and the on-behalf-of flow across three different clients is where most teams stall. Happy to compare notes or walk through what broke.