AGTNEWS
A prerelease .
Microsoft shipped a prerelease .NET package on July 28, 2026, that lets agents download reusable skill bundles from any server speaking the Model Context Protocol (MCP), an open client-server standard used for tool calls and context exchange in agent systems. The release, announced in a Microsoft devblog post, turns skills from something each app has to bundle into something a platform team can publish once and roll out centrally.
A skill, in this context, is a packaged bundle of instructions, reference resources, and optional scripts an agent can consult mid-task. Microsoft describes the underlying design as progressive disclosure: a server advertises each skill in a small index (~100 tokens), the agent pulls the full SKILL.md only when needed (under 5,000 tokens recommended), reads supporting resources on demand, and runs scripts only when it has to. The pattern is documented in Microsoft's conceptual documentation as an open spec (agentskills.io) rather than a Microsoft-owned format.
The new .NET package adds a way for agents to source those skills from a remote MCP server at runtime. The server exposes a discovery document at skill://index.json; the agent framework fetches it over the existing authenticated MCP connection, then pulls each skill's contents on demand. Agent code does not need to know how the skill is packaged. The same builder call, AgentSkillsProviderBuilder.UseMcpSkills(client), works for both shapes.
The two shapes matter because they have different blast radii. The first, skill-md, exposes the skill's SKILL.md and sibling resources as MCP resources, fetched individually. The second, archive, packages the whole skill as a single ZIP, TAR, or compressed TAR that the agent downloads, unpacks under a controlled directory, and serves. Archive skills are where the security story gets interesting, and where Microsoft's defaults are doing the most work.
AgentMcpSkillsSourceOptions exposes four knobs aimed squarely at the standard archive pitfalls: ArchiveSkillsDirectory to set the unpack path, ArchiveMaxFileCount to cap how many files a single archive can contain, ArchiveMaxSizeBytes to cap the compressed payload, and ArchiveMaxUncompressedSizeBytes to cap the post-decompression size. Microsoft treats remote executable content as untrusted by design: archive-skill scripts are never executed by the framework, and the three skill tools (load_skill, read_skill_resource, run_skill_script) require explicit approval by default. None of these are independent audit findings; they are vendor self-assertions in the devblog post and the conceptual documentation.
UseMcpSkills chains into the same AgentSkillsProviderBuilder that already accepts local file-based skills, so a single agent can carry private on-disk skills and also pull shared skills from a server. The same wiring hooks into Microsoft Foundry Toolbox: skills managed through the Foundry Skills API and attached to a toolbox become discoverable by .NET agents through that toolbox's MCP endpoint, with no additional integration code. A working sample lives in the agent-framework repository.
The trust boundary moves with the design. With skills shipped per app, the boundary is each application's code repository and build pipeline. With skills served from an MCP server, the boundary moves to the server's authentication, the channel's transport security, and the safety defaults applied to fetched content. For a regulated enterprise, that collapses a sprawling set of per-app code reviews into a single server-side review process. It also means a misconfigured archive knob on a single server can become a fleet-wide exposure point, which is why the explicit caps on file count, compressed size, and uncompressed size read as defensive defaults rather than as features.
Outside Microsoft, no adoption has been reported. The capability is .NET-only, single-vendor, and marked experimental in the devblog post. The MCP skills specification itself is described in the same post as still evolving, with shape changes expected before general availability. No third-party performance benchmarks or comparative coverage against other vendor MCP implementations appear in the source bundle. The devblog post is attributed to an unnamed 'Principal Software Engineer,' while the underlying conceptual documentation credits Sergey Menshykh; any human attribution in coverage should track which document is being cited.
The mechanism is concrete: a domain team writes a skill once, pins a version on the server, and every connected agent picks it up without a rebuild. The risk is also concrete: until the spec stabilizes and at least one large non-Microsoft customer ships against it, adoption is a bet on Microsoft staying the course.