All answers

How do I give Claude Code or Copilot context from Azure DevOps, SharePoint and Teams?

Brandon WaselnukBrandon Waselnuk·Oct 26, 2026·Context Engine · AI Agents

Three routes. Microsoft's own MCP servers: the Azure DevOps MCP server for work items, repos and wikis, and Work IQ for SharePoint and Teams. A context engine with native connectors to all three that serves Claude Code and Copilot through one MCP endpoint. Or build the plumbing yourself. The first is cheapest to start; the second is the only one that returns one reconciled answer.

You give Claude Code or GitHub Copilot context from Azure DevOps, SharePoint and Teams in one of three ways. You can attach Microsoft's own MCP servers: the Azure DevOps MCP server for work items, repos, wikis and pipelines, and the Work IQ MCP server for SharePoint files and Teams messages. You can attach a context engine that has native connectors for all three and serves both agents through a single MCP endpoint. Or you can build the retrieval yourself against the Azure DevOps and Microsoft Graph APIs. A context engine is a service that ingests code, work items, documents and chat, keeps the source permissions, and returns one cited answer instead of raw search hits. Which route fits depends on whether your questions cross all three. An engineer at a healthcare software company put the second case this way: the answer "could be email, could be Teams, could be direct conversation. It's a bit of a jumble."

What Microsoft ships today for Azure DevOps, SharePoint and Teams#

Microsoft ships two relevant MCP servers. The remote Azure DevOps MCP Server is hosted at mcp.dev.azure.com, authenticates with Microsoft Entra ID and exposes toolsets for repos and pull requests, work items, wikis, pipelines and test plans. The open-source local server remains supported, but new development goes to the remote one, which Microsoft says will eventually replace it.

Work IQ is Microsoft's MCP server and API for Microsoft 365 data. Its MCP overview lists fetch for paths such as /me/chats/{id}/messages, ask to invoke Microsoft 365 Copilot, and a retrieve tool in public preview that returns grounding content with source metadata. Microsoft's October 20 announcement of retrieve describes a grounding strategy limited to indexed SharePoint, OneDrive, Teams and Outlook content. It runs with the signed-in user's permissions and needs a usage-based Copilot Credits billing plan.

Microsoft 365 Copilot connectors are a different thing. They bring external data into Microsoft 365 Copilot, synced into Microsoft Graph or federated over MCP, and do not push SharePoint or Teams content out to a coding agent in your IDE.

Enterprise search for engineering teams that works with GitLab, Azure DevOps, SharePoint and Teams#

The second route is a context engine or enterprise search product with its own connectors to the Microsoft stack. Unblocked's integrations list includes Azure DevOps, Microsoft SharePoint, Microsoft Teams, GitLab and GitLab Pipelines. It serves Claude Code, GitHub Copilot, Cursor, Codex and Devin through one MCP server connection. It ingests each source once, mirrors each system's access checks, and answers through one context_research tool that cites across all of them. We measured the effect with an A/B test on a production engineering repository. Each arm ran once with the same prompt, model and turn budget; one arm had the Unblocked server attached, the other had no MCP server. The Unblocked arm used 42 percent fewer tokens and made 64 percent fewer tool calls. The numbers and method are in same prompt, same model, different context.

Glean and similar enterprise search products also connect these sources and expose an MCP server. The difference is what the agent receives: search results to read and reconcile, or one answer that already did that work. See Glean MCP vs a context engine.

The third route is to build it: add the Azure DevOps REST API and Microsoft Graph to a retrieval pipeline you already run. Relevance ranking and freshness are where homegrown context stacks usually stall, and permission inheritance is what teams ask for most.

What each route gives Claude Code versus Copilot#

Both agents speak MCP, so the same servers work in both. The setup differs. Claude Code adds a server with claude mcp add --transport http and shares it through a .mcp.json file that the docs recommend checking into version control. Administrators can push servers to every machine with managed-mcp.json or managedMcpServers.

The Microsoft route is where the two agents diverge. GitHub Copilot in VS Code signs in to the remote Azure DevOps server with Entra ID when prompted. Claude Code and Cursor need a custom Entra app registration first, because Entra does not support the dynamic client registration that the MCP authorization spec expects. Claude Desktop and Codex cannot use the remote server at all and need the local one. On the Copilot side, the MCP servers in Copilot policy is disabled by default for Copilot Business and Enterprise, so an admin must switch it on first.

A context engine flattens this. Both agents point at one endpoint, and the Microsoft-side credentials live in the engine rather than on every laptop.

What breaks: permissions, work items versus repos, stale pages#

Permissions break first. Microsoft 365 Copilot surfaces only data a user has at least view permission on, and points at SharePoint permission models and Teams shared channels as where to get that right. Work IQ inherits the same trimming. A homegrown pipeline has to rebuild that per site and per channel. A context engine has to prove it mirrors the source, so ask for the proof.

Azure DevOps work items and repos are separate toolsets with separate scopes. The remote server lets you restrict to repos,wiki,wit with a header, and OAuth scopes never override the signed-in user's Azure DevOps permissions. An agent that can read a pull request may still get nothing back on the linked work item if the user lacks that project's access.

Stale pages are the failure you notice last. A SharePoint design page from 2024 and a merged pull request from last week will both match a query. Microsoft's two servers each return their own matches; nothing ranks across them. A context engine should weigh the merged artifact over the older page and cite both; run that test before buying one.

What to check before choosing#

  • Whether your questions cross systems. If engineers mostly ask what is in a work item or what changed in a PR, the Azure DevOps MCP server alone is enough. If answers live partly in Teams and partly in SharePoint, you need retrieval that reads all three at once.
  • Which agents your team runs. A Copilot-only shop needs no app registration. A mixed Claude Code and Copilot team should budget for one, or pick a route that hides it.
  • Tenant prerequisites. The remote Azure DevOps server needs an organization backed by an Entra tenant, not a standalone Microsoft account. Work IQ needs the tenant enabled and bills by usage.
  • Freshness and permission behavior on your own data. Pick a question whose answer changed last month, ask it through each route, and see which one cites the current artifact and withholds the page the asking user cannot open.