Your agents can now discover and load Agent Skills directly from a Model Context Protocol (MCP) server. Instead of shipping every skill inside your application or copying skill folders into each deployment, you point an agent at an MCP server and it pulls the skills it needs on demand. A central team can publish skills once, and every agent across your organization picks them up without a redeploy. This is available today in .NET through the Microsoft.Agents.AI.Mcp package.For makers, this removes a distribution problem: you author a skill in one place and serve it to many agents. For enterprise leaders, it means domain expertise – expense policies, compliance workflows, data-analysis playbooks – can be governed centrally, versioned on a server, and rolled out consistently without touching application code.What MCP-based skills areAn Agent Skill is a portable package of instructions, resources, and scripts that gives an agent specialized capability using a progressive-disclosure pattern: the agent sees a short advertisement of each skill up front, then loads the full instructions and resources only when a task matches.MCP-based skills apply that same pattern, but the skills live on an MCP server rather than on local disk or in code. The server advertises its skills through a discovery document at skill://index.json, and the framework retrieves the referenced skill content through the authenticated MCP connection.The .NET implementation supports two ways a server can distribute a skill: skill-md – The server exposes the skill's SKILL.md and its sibling resources as MCP resources. The framework fetches them on demand, file by file, as the agent loads the skill and reads its resources. archive – The skill is packaged as a single archive (ZIP, TAR, or gzip-compressed TAR). The framework downloads it, unpacks it locally under a controlled directory, and serves the extracted files.Both types are consumed through the same builder API, so your agent code does not change based on how a skill is packaged.Why this mattersAuthor once, serve everywhere. A platform or domain team publishes skills to an MCP server. Any agent that connects picks them up – no per-agent packaging, no copying folders, no rebuild.Update without redeploying agents. When the server's skill content changes, connected agents get the new version the next time they discover skills. Policies and playbooks evolve on the server, not in every downstream application.Consistency across many agents. The same skill, from the same source, reaches every agent. That is the difference between "each team maintains its own copy of the expense policy" and "there is one expense policy, and everyone uses it."Guardrails for remote content. Skills that arrive over MCP keep the same progressive-disclosure discipline as local skills, with explicit controls for archive extraction and script execution (covered below).Getting startedMCP-based skills require the Microsoft.Agents.AI.Mcp NuGet package:dotnet add package Microsoft.Agents.AI.Mcp --prerelease[alert type="note" heading="Experimental API"]The MCP skills API is experimental and may change in future releases. The MCP skills specification is still evolving, and its details may be revised as the specification matures.[/alert]Connect an MCP client to the server that hosts your skills, then use the UseMcpSkills extension method on AgentSkillsProviderBuilder to add it as a source:using Microsoft.Agents.AI;using ModelContextProtocol.Client;// Connect to the MCP server that hosts the skillsawait using McpClient client = await McpClient.CreateAsync( new StdioClientTransport(new() { Name = "skills-server", Command = "dotnet", Arguments = [skillsServerPath, "--server"], }));// Build a skills provider that discovers skills over MCPvar skillsProvider = new AgentSkillsProviderBuilder() .UseMcpSkills(client) .Build();Add the provider to an agent through its context providers so the framework advertises the server's skills to the agent, and the agent can load and read them as it would local skills:using Azure.AI.OpenAI;using Azure.Identity;using OpenAI.Responses;AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential()) .GetResponsesClient() .AsAIAgent(new ChatClientAgentOptions { Name = "SkillsAgent", ChatOptions = new() { Instructions = "You are a helpful assistant. Use available skills to answer the user.", }, AIContextProviders = [skillsProvider], }, model: deploymentName);AgentResponse response = await agent.RunAsync( "Summarize our expense reimbursement limits for international travel.");Console.WriteLine(response.Text);The agent sees the skill advertised in its system prompt and, when the request matches, loads the relevant content. For a skill-md skill, the framework fetches SKILL.md from the server when the agent loads the skill. For an archive skill, it uses the skill archive downloaded from the server and extracted locally. In both cases, referenced resources are read as needed.Use case: a central skills server for many agentsSuppose a platform team owns the company's operational knowledge – expense policy, incident-response runbooks, and a data-classification guide. They host these as skill-md skills on an MCP server. A finance assistant, an on-call helper bot, and a data-governance agent all connect to that same server with the same UseMcpSkills(client) call shown above.None of the three agents bundles any of these skills. When the platform team updates the expense policy on the server, all three agents reflect the change on their next discovery – no coordinated release across teams.Because UseMcpSkills adds a source to the builder, you can compose it with local skills in the same provider. An agent can carry its own file-based skills and also pull shared ones from the server:var skillsProvider = new AgentSkillsProviderBuilder() .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "local-skills")) // team-owned, on disk .UseMcpSkills(client) // shared, from the server .Build();This includes Microsoft Foundry Toolbox – if your organization manages skills through the Foundry Skills API and attaches them to a toolbox, UseMcpSkills connects to that toolbox's MCP endpoint the same way it connects to any other MCP server. You author and version skills in Foundry, and your .NET agents discover them over MCP without additional integration work.Use case: distributing a skill as an archive, safelySome skills bundle several reference files – templates, lookup tables, checklists. Serving them as a single archive entry lets the server ship the whole package in one download. Because archive extraction writes remote content to local disk, it needs guardrails: an archive can be larger than expected, expand dramatically when decompressed, or contain more files than you intend to accept. Without bounds, a malformed or hostile archive could exhaust disk, memory, or CPU on the machine running the agent.For that reason, AgentMcpSkillsSourceOptions exposes a set of options that let you bound exactly how much an archive is allowed to consume before it is extracted and served:using Microsoft.Agents.AI;var skillsProvider = new AgentSkillsProviderBuilder() .UseMcpSkills(client, new AgentMcpSkillsSourceOptions { ArchiveSkillsDirectory = Path.Combine(AppContext.BaseDirectory, "extracted-skills"), ArchiveMaxFileCount = 50, ArchiveMaxSizeBytes = 2 * 1024 * 1024, // cap the download size ArchiveMaxUncompressedSizeBytes = 4 * 1024 * 1024, // cap the total unpacked size }) .Build();Each option guards against a specific class of abuse: ArchiveMaxSizeBytes caps the size of the archive that is downloaded, guarding against oversized payloads. ArchiveMaxUncompressedSizeBytes caps the total unpacked size, guarding against decompression-bomb archives that are tiny on the wire but expand to gigabytes on disk. ArchiveMaxFileCount caps how many files a single archive may contain, guarding against excessive-file-count archives.The framework downloads the archive, validates it against these limits, unpacks it under ArchiveSkillsDirectory, and serves the extracted SKILL.md and resources. An archive that exceeds any of these bounds is skipped, so an untrusted server cannot use skill distribution as a way to overwhelm the host.There is one more trust boundary around remote archive content:[alert type="important" heading="Archive scripts are never executed"]Scripts bundled in archive-type skills are never executed. Executable content downloaded from a remote MCP server is treated as untrusted by design – the framework serves the skill's instructions and resources, but will not run its scripts.[/alert]The rest of the skills governance model still applies. Skill tools such as load_skill, read_skill_resource, and run_skill_script require approval by default, giving you a human-in-the-loop checkpoint before an agent acts.Why this matters, restatedMCP-based skills turn Agent Skills into something you distribute rather than something you embed. Author a skill once, host it on an MCP server, and let every agent discover it on demand – updated centrally, governed centrally, and consumed the same way whether it arrives as skill-md resources or as a packaged archive. For teams building many agents against shared domain knowledge, that is the difference between maintaining copies and maintaining a source.To go deeper: MCP-based skills documentation MCP-based skills sample Skills in Microsoft Foundry Agent Skills for .NET Is Now Released Agent Skills in .NET: three ways to author, one provider to run them