# microsoft/mcp: What the Repository Actually Ships, and How to Install the Azure MCP Server

> The microsoft/mcp repository is the engineering home for Microsoft's MCP server implementations, not a single product. Here is what is inside, how the Azure MCP Server installs, and where the project stops being the right tool.

**microsoft/mcp** — Catalog of official Microsoft MCP (Model Context Protocol) server implementations for AI-powered data access and tool integration

- Repository: https://github.com/microsoft/mcp
- Stars: 3,720 · Forks: 631
- Language: C#
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-mcp

## What microsoft/mcp is, and what it is not

The README opens with a definition of Model Context Protocol itself: an open protocol that standardizes how applications provide context to large language models, with a client-server split into MCP Hosts (assistants and IDEs), MCP Clients (the connectors inside a host), and MCP Servers (the services exposing context and capabilities). That framing matters because microsoft/mcp is not one of those servers. It is a catalog plus shared engineering. The README says the repository "contains core libraries, test frameworks, engineering systems, pipelines, and tooling for Microsoft MCP Server contributors to unify engineering investments; and reduce duplication and divergence."

That explains the top-level layout. Alongside README.md and LICENSE you find core/, eng/, tools/, docs/, Resources/ and servers/, plus build files such as Directory.Build.props, Directory.Packages.props, Microsoft.Mcp.slnx and global.json. The servers/ directory is where the actual server implementations live, and the README's table lists two that are built from this repository: Azure MCP and Microsoft Fabric MCP. Everything else in the README's longer list (Microsoft Foundry, Azure Resource Manager, and the rest of the catalog) is documented as living in other repositories or as a remote endpoint, which is why the page is titled as a catalog of official Microsoft MCP server implementations rather than as a single server's manual.

The audience follows from that. If you are a contributor to a Microsoft MCP server, this is the monorepo you work in. If you are an engineer trying to give an AI agent access to Azure resources, you are a consumer of one subdirectory, and most of the repository is irrelevant to you.

## Azure MCP and Fabric MCP: two servers, one build system

The README's table is the clearest statement of scope. Azure MCP and Microsoft Fabric MCP each get a row, and each row links to seven artifacts: a README, source code, a CHANGELOG, a releases query, documentation, a troubleshooting guide and a support document. For Azure MCP those resolve to servers/Azure.Mcp.Server/README.md, servers/Azure.Mcp.Server/CHANGELOG.md, servers/Azure.Mcp.Server/TROUBLESHOOTING.md and servers/Azure.Mcp.Server/SUPPORT.md inside this repository, with prose documentation at learn.microsoft.com/azure/developer/azure-mcp-server/. Fabric MCP follows the same pattern under servers/Fabric.Mcp.Server/, with documentation at learn.microsoft.com/fabric/.

The duplication the README mentions is visible in the shared top-level files. Directory.Build.props, Directory.Packages.props and Directory.Build.targets are MSBuild-level shared configuration, which is the standard .NET way to pin package versions and compiler settings once for many projects. global.json pins the SDK. Microsoft.Mcp.slnx is the solution file that ties the server projects together. The primary language of the repository is C#, consistent with that toolchain.

One consequence is worth stating plainly: the release cadence in the README's release list is per server, not per repository. Azure.Mcp.Server-3.0.0-beta.45 was published on 2026-09-17, with beta.44 on 2026-09-15 and beta.43 on 2026-09-12. Three beta builds in five days tells you the server surface is still moving. The last push to the repository was on 2026-09-18, and the repository is not archived, so work is ongoing, but ongoing work on a beta line is not the same as a frozen interface.

## Installing the Azure MCP Server from this repository

The README does not give a single canonical `dotnet tool install` line for the Azure MCP Server. What it gives is a row of install badges, and those are the concrete paths it endorses: VS Code and VS Code Insiders via the extension ms-azuretools.vscode-azure-mcp-server, Visual Studio via the marketplace item github-copilot-azure.GitHubCopilotForAzure2022, IntelliJ IDEA via a JetBrains plugin, Eclipse via the Azure Toolkit for Eclipse, and a separate Claude Code section linked from the Azure MCP README. If you are in one of those hosts, follow the badge rather than improvising a command.

The repository also ships a Dockerfile, which is the path to take if you want to run a server yourself rather than through an IDE extension. It is a runtime image built on mcr.microsoft.com/dotnet/runtime-deps:10.0-alpine, and it requires two build arguments:

```dockerfile
FROM mcr.microsoft.com/dotnet/runtime-deps:10.0-alpine AS runtime
ARG PUBLISH_DIR
ARG EXECUTABLE_NAME
COPY ${PUBLISH_DIR} /mcp-server/
WORKDIR /mcp-server
```

The file errors out if either PUBLISH_DIR or EXECUTABLE_NAME is empty, copies the published output into /mcp-server, checks that the named executable exists, marks it executable, creates a non-root user named mcp, and sets the entrypoint to `./server-binary server start`. So the image does not build a server from source; you publish first and point the build at the result. Passing an empty PUBLISH_DIR fails the build with "ERROR: PUBLISH_DIR build argument is required", which is a useful signal when a CI job silently produces no output.

For a first real use, the honest starting point is the host you already have. Open VS Code, install the Azure MCP extension from the badge in the README, and the server registers as a local MCP server for that workspace. The README describes the Azure server as usable alone or together with the GitHub Copilot for Azure extension, so both routes are supported. What you should see is the server appearing in your host's MCP server list; the README does not document a standalone CLI invocation beyond the `server start` entrypoint baked into the image.

## Remote servers in the catalog are not in this repository

The distinction between local and remote is stated explicitly in the catalog entries, and it changes what you can verify. Azure MCP is typed as `Local`, meaning the server process runs on your machine, which is why it has a Dockerfile and an install badge per IDE. Microsoft Foundry and Azure Resource Manager are typed as `REMOTE` with endpoints given as https://mcp.ai.azure.com and https://mcp.management.azure.com respectively. For those, the install badge is a VS Code deep link that registers an HTTP MCP server by URL; there is no local binary to pin.

This is the part of the README most likely to mislead a reader skimming the page. The heading asks which MCP servers are available from Microsoft, and the list is long, but only the two rows in the earlier table are built from this repository. Foundry's documentation points at learn.microsoft.com/azure/ai-foundry/mcp/get-started, and Azure Resource Manager's source lives at Azure/Azure-Resource-Manager-MCP, a different GitHub organization path. If you file an issue here about Foundry behavior, you are in the wrong place, and the README's own structure says so.

For a team evaluating the catalog, the practical reading is: this repository is the supply chain for the local Azure and Fabric servers, and a pointer index for everything else.

## Where microsoft/mcp is the wrong choice

The beta versioning is the first limitation, and it is not cosmetic. The current Azure MCP Server line is 3.0.0-beta.45. A beta suffix on a tool that an AI agent calls means the tool names, parameters or responses can change between builds, and an agent prompt tuned against beta.43 may not behave the same against beta.45. If your integration needs a stable contract, this is the wrong moment to depend on it without pinning.

The second limitation is host coupling. The README's install paths are all IDE or assistant specific: VS Code, VS Code Insiders, Visual Studio, IntelliJ, Eclipse, Claude Code. There is no documented generic stdio command in the top-level README for wiring the Azure server into an arbitrary MCP host. The Dockerfile gives you a container with a `server start` entrypoint, but the README does not document the transport or the arguments that entrypoint expects. Teams running a bespoke agent framework will have to read servers/Azure.Mcp.Server/README.md and the troubleshooting guide rather than the catalog page.

The third is scope. If your data lives in AWS, Google Cloud or a self-hosted database, nothing here addresses it. The two servers built from this repository are Azure and Microsoft Fabric. The catalog lists other Microsoft servers, but they are remote endpoints or separate repositories, and adopting one of those is a different decision with different documentation.

Authentication is the gap I would flag hardest. The README's Azure section points to a Claude Code install link but does not describe credentials, token scopes or what happens when a session expires. SUPPORT.md and TROUBLESHOOTING.md exist for exactly that reason, and they are where a production rollout should start.

## Alternatives and how the approach differs

The nearest alternative is not a competing MCP catalog but the Azure CLI and the Azure SDKs. Those give you imperative, versioned, scriptable access to the same Azure surface: you write `az` commands or SDK calls, you control the output format, and you can pin the tool version in CI. The difference in approach is who decides the sequence of calls. With the CLI, your code decides. With an MCP server, the model decides which tool to invoke based on the conversation, and the server's tool descriptions shape that choice. That is the whole point of the protocol, and it is also why the tool surface is harder to regression-test than a shell script.

Within the MCP world, the alternative is to write your own server against the MCP specification instead of adopting Microsoft's. The README links to modelcontextprotocol.io for the specification, and the repository's core/ directory is evidence that Microsoft factored shared server machinery out of the individual servers. Building your own means owning the tool definitions, the auth flow and the release cadence, and it means you are not exposed to a beta version bump you did not choose. The trade-off is that you also do not get the Azure service coverage the Azure MCP Server already implements.

A third option, for Foundry or Azure Resource Manager specifically, is to use the remote endpoints the catalog lists rather than anything in this repository. That removes the local install entirely, at the cost of depending on a hosted service and its availability.

## Licence, contribution and what an upgrade actually costs

The repository is MIT licensed, with LICENSE and NOTICE.txt at the top level. MIT is permissive: it allows commercial use and modification with attribution and without a copyleft obligation on your own code. That is a statement about the repository's terms, not legal advice, and a redistributed container image still carries whatever notices the bundled dependencies require, which is what NOTICE.txt is for.

Upgrade cost is dominated by the beta cadence. Because releases are per server and the Azure line is at 3.0.0-beta.45, the meaningful question is not how often the repository changes but whether the tool definitions your prompts rely on changed. The CHANGELOG at servers/Azure.Mcp.Server/CHANGELOG.md is the file to read before bumping, and it is linked from the README's table for exactly that purpose. If you consume the server through an IDE extension, the extension's update channel sets your cadence and you have less control; if you build the Docker image yourself, you control when PUBLISH_DIR points at a newer publish output.

Contribution expectations are documented separately. CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and AGENTS.md sit at the top level, and the README's stated purpose of unifying engineering investments across contributors is the rationale for the shared build files. The repository is not archived and the last push was on 2026-09-18, so the project is receiving changes, but the release list shows those changes landing on a beta line rather than a stable one.

## Conclusion

Adopt microsoft/mcp if you already run Azure or Microsoft Fabric workloads and want an AI host such as VS Code, Visual Studio, IntelliJ, Eclipse or Claude Code to reach those services through one local server. Do not adopt it if you need a stable, versioned surface: the current Azure MCP Server releases are 3.0.0-beta.45, beta.44 and beta.43, so the tool surface can shift between builds. Before wiring it into anything shared, read servers/Azure.Mcp.Server/TROUBLESHOOTING.md and SUPPORT.md, and confirm which authentication path your host uses, because the README points to a Claude Code section rather than describing credentials in the top-level file.

## FAQ

### What is microsoft/mcp?

It is the repository that holds core libraries, test frameworks, pipelines and tooling for Microsoft MCP Server contributors, plus the source for the Azure MCP and Microsoft Fabric MCP servers. The README also uses it as a catalog pointing to other Microsoft MCP servers that live elsewhere or run as remote endpoints.

### How do I install the Microsoft MCP server?

The README gives install badges rather than a single command: VS Code and VS Code Insiders use the extension ms-azuretools.vscode-azure-mcp-server, Visual Studio uses the marketplace item github-copilot-azure.GitHubCopilotForAzure2022, and IntelliJ and Eclipse have their own plugin links. The Azure MCP README also has a separate Claude Code section.

### Can I use microsoft/mcp with VS Code?

Yes. The Azure MCP catalog entry lists VS Code and VS Code Insiders install links, and the README notes the server can be used alone or with the GitHub Copilot for Azure extension in VS Code. Microsoft Foundry and Azure Resource Manager are also installable in VS Code, but as remote HTTP servers at mcp.ai.azure.com and mcp.management.azure.com.

## Sources

- [Issues](https://github.com/microsoft/mcp/issues)
- [License: MIT](https://github.com/microsoft/mcp/blob/main/LICENSE)
- [microsoft/mcp on GitHub](https://github.com/microsoft/mcp)
- [README](https://github.com/microsoft/mcp/blob/main/README.md)
- [Releases](https://github.com/microsoft/mcp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-mcp