Microsoft Learn MCP Server: a remote endpoint for grounding agents in Microsoft docs
Official Microsoft Learn MCP Server and CLI tool – powering LLMs and AI agents with real-time, trusted Microsoft docs & code samples.
At a glance
- What is it?
- Microsoft's MCP server at learn.microsoft.com/api/mcp exposes three read-only tools over Streamable HTTP with no authentication, and the companion @microsoft/learn-cli package puts the same tools in a terminal. The design is narrow on purpose, which is both its main selling point and its main constraint.
- Who is it for?
- Adopt it if your agent needs current Microsoft and Azure documentation and you want zero key management: the endpoint is remote, unauthenticated, and the CLI installs agent discovery into .github/skills/, .claude/skills/ or .agents/skills/ depending on scope. Do not adopt it if you need write access, non-Microsoft sources, or a self-hosted server, because the repository documents a hosted endpoint and a client-side CLI, not a deployable service.
- Can I use it commercially?
- Yes, with credit. CC-BY-4.0 allows commercial use as long as you credit the authors and indicate what you changed. It is written for creative content, so check how it applies to any code.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: an agent that answers Azure questions from stale training data
The README opens with a blunt claim: "Stop AI Hallucinations." The failure it names is specific. An assistant trained on an older snapshot of Microsoft documentation will invent Azure SDK methods or suggest packages that do not exist, and the README's own framing is that the resulting code fails to compile. The alternative it rejects is generic web search, described as potentially scraping insecure blogs or malicious sites. Between those two options the project positions a third: direct retrieval from first-party Microsoft documentation, exposed through the Model Context Protocol.
The intended audience is anyone running a coding agent that touches Microsoft or Azure surfaces. The README lists Claude, Cursor, Copilot and Codex as example clients, and the sample prompts are all Microsoft-shaped: Azure CLI commands for a Container App with a managed identity, regional availability of a model, IHttpClientFactory in a .NET 8 minimal API, Python code for an evaluation SDK. If your agent never writes Azure configuration or .NET code, the retrieval corpus is largely irrelevant to you.
Three read-only tools behind one HTTP endpoint
The architecture is unusually simple because there is almost nothing to host. The server is a remote endpoint at https://learn.microsoft.com/api/mcp, reached over Streamable HTTP. The README states plainly that the URL is meant for use inside a compliant MCP client and that opening it in a browser may return 405 Method Not Allowed. There is no local process to supervise, no container to run, and no credentials to rotate.
The tool surface is three functions. microsoft_docs_search takes a query string and performs semantic search against Microsoft technical documentation. microsoft_docs_fetch takes a url and converts that documentation page to markdown. microsoft_code_sample_search takes a query and an optional language filter and returns official Microsoft and Azure snippets. All three are retrieval operations. Nothing in the documented table writes, executes, or mutates anything, which bounds the blast radius of a misbehaving agent to wasted tokens and wrong answers rather than changed infrastructure.
Two experimental additions sit alongside the core endpoint. An OpenAI-compatible variant at /api/mcp/openai-compatible follows the OpenAI MCP specification for Deep Research models. A maxTokenBudget query parameter, shown as ?maxTokenBudget=2000, truncates search responses to a token ceiling. The README labels both as under active development and subject to change, so treat them as moving parts rather than contract.
Getting it running: a JSON block or an npx command
For MCP clients, the README gives a standard config block with a servers object containing microsoft-learn, type set to http, and the endpoint URL. VS Code users get one-click install badges, including a separate badge for VS Code Insiders that appends an insiders quality parameter to the redirect URL.
The CLI path is separate. npx @microsoft/learn-cli search "azure functions timeout" runs without installing anything. A global install via npm install -g @microsoft/learn-cli exposes the mslearn command, so the same query becomes mslearn search "azure functions timeout".
There is a second command family that the README is careful to distinguish from the npm install itself: "Installing the npm package alone does not install agent discovery." Discovery is installed by mslearn setup --cli, which defaults to the user profile, or mslearn setup --cli --project for the current repository. Auto-detection can be overridden with --copilot, --claude or --codex, and the flags combine for multiple agents. Removal is scoped the same way through mslearn remove --cli. The target directories are listed explicitly: ~/.copilot/skills/ and .github/skills/ for GitHub Copilot, ~/.claude/skills/ and .claude/skills/ for Claude Code, ~/.agents/skills/ and .agents/skills/ for Codex. The README also notes that this workflow does not configure MCP and does not install agents outside those plugin ecosystems, naming Cursor as an example of what it will not touch.
What the endpoint cannot do, and where the documentation runs out
The clearest limitation is scope of corpus. Retrieval is restricted to Microsoft documentation and Microsoft or Azure code samples. If your work mixes AWS, Google Cloud and Azure in one repository, this server grounds only the Azure third of it, and the agent still needs another source for the rest. The supply-chain argument in the README, that the tool only accesses first-party documentation, is the same property that produces this gap.
The second limitation is that the project is not something you deploy. The repository is TypeScript and the licence is CC-BY-4.0, which is a content licence rather than a software licence, and that is a reasonable signal about what the artifact mainly is: documentation, a client-side CLI, and pointers to a hosted service. Nothing in the supplied material describes a self-hosting path, a Docker image, or an on-premises deployment. An organisation that cannot send queries to a public Microsoft endpoint has no documented route here.
A third gap is operational. The README warns that the endpoint is experimental in places and that features may change based on feedback, and there are no releases retrieved for this repository. There is no documented rate limit, no published quota, and no status page in the material. The README claims "high search capacity" without quantifying it, which is the kind of claim you cannot plan against. The maxTokenBudget parameter controls response size, not request volume.
Compared with running your own retrieval pipeline
The obvious alternative is the one most teams already have: a general web search tool wired into the agent, or a self-managed RAG index over documentation you crawl yourself. The difference in approach is not subtle. A web search tool returns whatever ranks, including third-party blogs and outdated Stack Overflow answers, and the agent must judge source quality on its own. A self-managed index gives you control over what is included and how it is chunked, but you own the crawl schedule, the embedding model, the freshness problem, and the storage. When Microsoft changes a page, your index is wrong until your next ingest.
The Learn MCP server sidesteps the ingest problem entirely because retrieval happens against the live service at query time, and it sidesteps the source-quality problem by refusing to index anything outside Microsoft's own documentation. The cost is that you inherit Microsoft's tool surface, its three fixed operations, and its availability. You cannot add a tool, change the ranking, or pin a documentation snapshot for reproducibility. For a team whose agent writes Azure Bicep and .NET code, that trade is usually favourable. For a team that needs citations from a frozen corpus for compliance reasons, a live endpoint is the wrong shape.
Maintenance cost and the licence question
Day-to-day maintenance is close to zero on the client side. There is no key to rotate, no server to patch, and no index to rebuild. The recurring work is configuration drift: the CLI writes discovery artifacts into agent-specific directories, and the README's table shows six paths across three agents and two scopes. If you run mslearn setup --cli --project in a repository, those files land in .github/skills/, .claude/skills/ or .agents/skills/ and become part of the repository's tracked content. mslearn remove --cli exists precisely for that, and the README notes that removal only detects agents with CLI-managed artifacts, so hand-edited files are your responsibility.
The licence is CC-BY-4.0, which is a Creative Commons attribution licence rather than a permissive software licence such as MIT or Apache-2.0. That matters for anyone planning to vendor the repository's content into a product or redistribute modified material, because attribution conditions attach. It also means the licence says little about patent grants or about the hosted endpoint's terms of use, which the supplied material does not cover at all. If you intend to redistribute anything from this repository, read the licence text and the Learn site terms rather than assuming the GitHub licence label settles it. This is not legal advice.
Who should wire this in, and what to check before you do
The fit is a team whose agents write Microsoft and Azure code and who want grounding without operating retrieval infrastructure. The one-click VS Code install and the keyless endpoint mean a single developer can validate the whole thing in an afternoon by asking an agent for Azure CLI commands and checking whether the answer cites current documentation.
The misfit is anyone who needs non-Microsoft sources, write operations, a self-hosted deployment, or a frozen documentation snapshot. The three tools are read-only by design, the corpus is first-party by design, and the supplied material describes no deployment path for the server itself.
Before adopting, verify three things against your own environment. Confirm your client speaks Streamable HTTP, since the README states the URL does not work from a browser. Run mslearn search "azure functions timeout" from a terminal to confirm the CLI reaches the service independently of any MCP client. Then decide whether discovery artifacts belong in user scope or project scope, because that choice determines whether .github/skills/, .claude/skills/ or .agents/skills/ ends up committed. The maxTokenBudget parameter is worth testing early if your agent's context window is tight, since it is the only documented lever over response size.
Editorial conclusion
Adopt it if your agent needs current Microsoft and Azure documentation and you want zero key management: the endpoint is remote, unauthenticated, and the CLI installs agent discovery into .github/skills/, .claude/skills/ or .agents/skills/ depending on scope. Do not adopt it if you need write access, non-Microsoft sources, or a self-hosted server, because the repository documents a hosted endpoint and a client-side CLI, not a deployable service. Verify first that your client speaks Streamable HTTP, then run mslearn search "azure functions timeout" from a terminal to confirm the tool surface behaves as the README describes.
Community notes