Development workflows span terminals, IDEs, background agents, and custom assistants. What matters is whether they draw from the same current source. Learn MCP Server gives any MCP-compatible agent direct access to current Microsoft documentation – one endpoint, nothing to install, no authentication required.

What does that look like in practice? You give your coding agent the prompt: “create a CLI script to deploy Azure AI Foundry.” It reaches for az ml, the Azure ML extension – the right answer a year ago. It hits a Python dependency crash, spends 15 tool calls debugging import paths, and produces a script targeting a deprecated API surface. Another developer enters the same prompt with Learn MCP Server connected. The agent checks trusted up-to-date documentation first, finds az cognitiveservices (the current Foundry resource model), and delivers a working deployment script with model provisioning on the first try. Same model. The difference was whether the agent had access to current product documentation while it worked.

Agents are good at writing code, but they don’t know which API shipped last month. Language models training data has a cutoff, while technology evolves continuously. As a result, agents produce code that looks correct but may target deprecated APIs – leading to dependency failures, missing capabilities, or scripts that break when the old surface is retired. You can work around this with prompt engineering: add constraints, pin versions, test the output, iterate. That works. It also means you’re doing the verification the agent should be doing for you.

The real world test

We gave a coding agent a simple task: generate a bash script to deploy a Foundry instance. The agent chose the az ml extension, which uses az ml workspace create --kind hub to create Foundry resources. This was the documented approach until recently. When the extension failed to load (a Python dependency conflict with rpds-py), the agent started debugging: reinstalling pip packages, testing Python import paths, checking system vs. CLI Python versions, inspecting .so files. Fifteen tool calls later, the extension loaded, and the script ran – but it targeted the old hub-and-project model through the ML workspace API.

Then we used the same prompt, same model, but with Microsoft Learn MCP Server connected. The agent queried Microsoft Learn for current Foundry deployment guidance, found the quickstart documentation, and used az cognitiveservices – the current API surface for Foundry resources. No extension to install. No dependency issues. The script created an AIServices resource, a project, and deployed a model with version pinning, SKU configuration, and capacity settings. It had interactive prompts, idempotency checks, and connection info output. The agent didn’t need to be told which API to use. It read the docs. The result: working code on the first try, no manual correction, and fewer steps from prompt to production.

	Without grounding	With grounding
Prompt	“create a CLI script to deploy Azure AI Foundry”	Same
Agent’s first action	Web search	Microsoft Docs Search
API chosen	az ml (deprecated for Foundry)	az cognitiveservices (current)
Blocked by	rpds.rpds Python dependency crash	Nothing
Debug steps before producing code	15+ tool calls	0
Model deployment included	No	Yes (gpt-4.1-mini, versioned, with SKU)
Result	Script targeting old hub-and-project API	Working end-to-end deployment script

What is Learn MCP Server

Learn MCP Server gives agents direct access to Microsoft Learn documentation, code samples, and guidance through the Model Context Protocol (MCP). Instead of relying on training data that’s months or years old, agents can search and retrieve current, official content as part of their reasoning.

It works with any MCP-compatible client: GitHub Copilot CLI, Visual Studio Code, Visual Studio, and others like Claude Code. The server is remote (https://learn.microsoft.com/api/mcp, which MCP clients understand) – nothing to install or host. No authentication required. You can even use Learn MCP Server in agent you build in Foundry or Copilot Studio.

When a Microsoft technology is in scope – deploying an Azure service, migrating a .NET application, configuring a Bicep template – the agent can query Learn for current guidance and reason over it alongside your codebase. That means fewer outdated patterns, fewer manual verification loops, and docs showing up where the decisions happen instead of in a separate browser tab.

Set it up

GitHub Copilot CLI:

/plugin install microsoftdocs/mcp 
/restart

VS Code: Open the extensions pane, search for “@agentPlugins microsoft-docs” and select Install.

Try it

Connect the tools you already use to Learn MCP Server and try it on your next task that touches a Microsoft product or service. The quickest way to see the difference is to ask your agent something that changed recently – a new API, a renamed service, a deprecated flag – and see whether it gets it right on the first try.

Connect with us in the Learn MCP Server repository for additional configurations and more information.