Agent Skills — folders of instructions, scripts, and resources that Claude loads on demand to perform specialized tasks — depend on server-side infrastructure: they execute inside Anthropic's code execution container. That dependency is exactly why their platform availability is uneven. Where Anthropic operates the serving stack, skills exist; where a cloud provider operates it, they currently don't. If document-generation skills (PowerPoint, Excel, Word, PDF) or custom organizational skills are part of your agent plans, this split should influence which door to Claude you pick.
The availability picture
| Surface | Agent Skills (Messages API) | Notes |
|---|---|---|
| Claude API (first-party) | Beta | Pre-built (pptx, xlsx, docx, pdf) and custom skills |
| Claude Platform on AWS | Beta | "Inherits the same Skills behavior as the Claude API" per Anthropic's docs |
| Amazon Bedrock | Not supported | Absent from all Skills availability statements |
| Google Vertex AI | Not supported | Google's docs: server tools are not supported for Claude |
| Microsoft Foundry | Beta — Hosted on Anthropic only | Not available on Hosted-on-Azure deployments |
The Foundry row needs unpacking, because Foundry is the only provider-operated platform with skills at all. Microsoft offers Claude in two hosting versions: Hosted on Azure (the model runs on Azure infrastructure end-to-end, generally available) and Hosted on Anthropic (requests are served from Anthropic's infrastructure outside Azure). Agent Skills — like the MCP connector — require the Hosted on Anthropic deployment. That's a real governance decision, not a checkbox: choosing skills on Foundry means your inference traffic leaves Azure, which may matter to teams who picked Foundry precisely to keep everything inside their Azure boundary. Microsoft's own Agent Framework documentation demonstrates the flow, running Anthropic's pptx skill against Foundry with the code interpreter tool — the same request shape as the first-party API.
On Bedrock and Vertex the absence is consistent with the rest of the server-side tool story: neither platform offers Anthropic's code execution tool, which skills require. Google's partner-model docs state the general rule plainly — Claude on Google Cloud supports client tools, but server tools are not supported.
The workaround that works everywhere: the Agent SDK
The availability table above describes the Messages API skills surface — the one where you upload skills to Anthropic and attach them via the container parameter. There is a second way to run skills: the Claude Agent SDK loads skills from .claude/skills/*/SKILL.md on your own filesystem, with no API upload involved, and executes them in your own environment. Because the Agent SDK is the documented agent path on all four 3P surfaces — CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_ANTHROPIC_AWS, CLAUDE_CODE_USE_VERTEX, and CLAUDE_CODE_USE_FOUNDRY — a Bedrock or Vertex shop can still get skill-shaped behavior by running agents through the SDK rather than raw Messages API calls.
One more trap: skills don't sync across surfaces
Custom skills are stored separately per surface. A skill uploaded to claude.ai, a skill uploaded via the Skills API, and a skill sitting in a Claude Code or Agent SDK .claude/skills/ directory are three independent copies with different sharing scopes — per-user on claude.ai, workspace-wide on the API, personal or per-project on the filesystem. If your organization standardizes on a skill, plan for distributing and versioning it across surfaces yourself; nothing propagates automatically. The runtime environment also differs by surface — API skills run without network access, filesystem skills don't — which is covered in Agent Skills Runtime Constraints Differ by Surface.
Where to go next
For the request shape and beta headers, see Agent Skills on the Messages API; for how skills stay cheap in context, the three-level loading model; and for the parallel story on MCP, the MCP connector platform split. The feature matrix shows the whole landscape at a glance.