You are wiring an agent to Cloudflare. You have a Workers project to deploy, and you already know the routine: point the agent at Cloudflare's API MCP server so it can call the API. Then comes the part you dread, which is making sure it knows how Cloudflare wants things done. In the past that meant a second step, installing skills as files, keeping them current, and hoping the agent found them.
A short changelog entry from Cloudflare, dated October 10, changes that routine. It is titled "Cloudflare API MCP server serves Cloudflare skills," and it is only three sentences long, with no figures. The company says its API MCP server "now serves Cloudflare skills through the Skills over MCP extension. MCP clients that support the extension discover the skills with skills/list and read their files at skill:// / ." To use them, you add one URL: the same MCP server you would already use to call Cloudflare's API.
Because the entry is so small, the post reads its significance from what it joins. For weeks the APIs.io series has covered two halves separately. Skills are files a developer installs. MCP servers are the tools an agent calls. Two weeks ago Apify measured that a skill costs about a hundred tokens until a task needs it, while an MCP connection's tool definitions sit in context on every turn. Cloudflare now puts the procedure and the tools behind the same endpoint, discovered by the same client, under the same authorization. So the agent you connect gets the playbook for using Cloudflare without a separate install.
There is a catch, and it is in the phrasing. Only "MCP clients that support the extension" will see the skills. If your client does not, you connect to the same server and the playbook simply is not there. Check that before you assume it works.
The catalog holds the surfaces being joined, and this is where the post turns to Cloudflare's own record. The Cloudflare provider page lists 650 API pages, all reachable through the API MCP server. The record already carries the Cloudflare Agents API and Cloudflare Workers API pages that the skills most often describe, so your Workers deploy sits squarely inside what the catalog already tracks. The agentic access profile maps 3,118 operations, 1,576 of them acting, meaning the agent behind your one URL can do things, not only read.
The scores say the same thing. On the Agent Readiness score, both the MCP server and agent skills are lit, along with fourteen other dimensions. The Kin Score is 81.3, in the exemplar band, and Agent Readiness is 74.8, agent-native. This is also the fourth Cloudflare story the series has run in nine days, and each has filled in a piece of one design: authorization as a library, durability as a lifecycle, search as a metered gateway tool, and now procedure delivered alongside the tools.
The catalog has measured skills and MCP servers as two separate dimensions. Cloudflare has made them one connection. That matters for how the rubric reads it: a provider that serves its skills over its MCP server has made them discoverable by the only party that needs them, the agent already connected.
What you take away is practical. When you evaluate a provider for your agent, stop treating skills and tools as two installs. Ask whether the playbook arrives through the same endpoint as the tools, under the same authorization. For Cloudflare, the answer is now yes, with one condition you can test today: whether your MCP client supports the Skills over MCP extension.
Read the original: https://apis.io/2026/10/21/cloudflare-serves-its-skills-through-its-own-mcp-server/