This week the APIs.io network added two new layers — skills.apis.io and mcp.apis.io — to index the agent-surface artifacts API providers are now shipping alongside their traditional documentation and OpenAPI specs. They join Capabilities as a third axis on the same provider catalog. Each sits in the More → Agent surfaces dropdown across every site in the network.
The headline counts after the first index pass:
| Layer | Providers | Artifacts | Source |
|---|---|---|---|
| skills.apis.io | 82 | 846 SKILL.md files |
Cloned from each provider’s declared skill repo |
| mcp.apis.io | 224 | 239 servers | Declared in each provider’s apis.yml |
What’s in the data
Every provider on the network publishes a Git-versioned APIs.json profile in their apis.yml. Among the property types are type: AgentSkill and type: MCPServer, which point at the canonical source of each artifact. The build pipeline pulled them out:
-
For MCP, the source is usually
github.com/<org>/<repo>plus a smaller set of npm packages, PyPI packages, marketplace listings, and hosted endpoints. URL host distribution: github.com (197), ai-gateway.mcp.cloudflare.com (3), browsermcp.com (2), aws.amazon.com (2), and the long tail. We index the entry verbatim and classify the install method by host. -
For skills, the
AgentSkillproperty points at a repo whose tree we walk forSKILL.mdfiles. EachSKILL.mdis a Claude Agent Skill — a YAML-frontmatter file withname,description, and (often)suggest_whentrigger conditions, plus a body that defines the actual procedure. 102 providers declare anAgentSkillURL; of those, 79 repos turned out to actually containSKILL.mdfiles (some are leftover Box-Skills-Kit / Skills-Based-Volunteering / postmark-skills type misfires from the property-type land grab — corrections inbound).
After the walk: 846 SKILL.md files. Each gets its own page with the full skill body rendered inline (wrapped in a Liquid raw block so embedded Mustache / Handlebars / Tailwind config blobs don’t break the Jekyll parse), the GitHub source link, and SoftwareApplication JSON-LD typed applicationCategory: AgentSkill.
Who’s actually shipping skills
The distribution is heavily concentrated in the top quartile. The ten leading providers by SKILL.md count:
| Provider | Skills |
|---|---|
Amplitude (builder-skills) |
118 |
Salesforce Commerce Cloud (b2c-developer-tooling) |
110 |
Microsoft Power Apps (power-platform-skills) |
104 |
| Microsoft Power Platform | 104 |
Harness (harness-skills) |
88 |
Hookdeck (webhook-skills) |
78 |
Microsoft 365 Copilot (skills-for-copilot-studio) |
62 |
| Visual Studio | 62 |
Databricks (databricks-agent-skills) |
52 |
Webflow (webflow-skills) |
50 |
These aren’t tutorial directories — they’re 50–120 named, scoped procedures with trigger conditions. Amplitude’s builder-skills repo has 118 SKILL.md files covering everything from “Diagnose Activation” to “Know Before You Go Pre-Call Intelligence.” Salesforce Commerce Cloud’s b2c-developer-tooling has 110 skills covering the storefront, ocapi, sfra, and headless commerce flows.
The middle of the distribution: 20–50 skills per provider. WordPress, Hugging Face, Apollo GraphQL, Binance, FusionAuth, Pulumi, Appwrite, SigNoz, Appium, OpenSearch, Apollo Config, Mixpanel, TrueFoundry, Prismatic, MongoDB, Wix, Canva, and the rest.
The long tail: 60 providers with 2–18 skills each — Atlassian Forge, AssemblyAI, Docsify, Denodo, MailerLite, ngrok, Restate, ScreenshotOne, SerpAPI, Northflank, SAP, Runway, Temporal, Tuya, Veryfi, Shippo, WunderGraph. These are typically <vendor>-skills or <vendor>-agent-skills repos shipping a focused handful.
Who’s shipping MCP
The MCP surface is wider but shallower: 224 providers ship at least one official MCP server, with 239 total server entries. Almost all are open-source GitHub repos; the rest are npm packages, doc-only references (Adobe Express, Apidog, Beehiiv), or hosted endpoints (Cloudflare AI Gateway, Browser MCP, Sourcegraph).
The format diversity matters because the install path differs sharply: a GitHub-hosted MCP server gets a paste-able Claude Desktop claude_desktop_config.json snippet on its detail page; a hosted endpoint just gets a URL; a marketplace listing gets a link out. The per-server pages classify by install method and surface the relevant install hint inline.
What’s distinct about the MCP universe vs. the skills universe:
- Breadth over depth. MCP has ~3× more providers but a similar artifact-per-provider ratio (1.07 servers/provider vs. 10.3 skills/provider). That makes sense — an MCP server wraps an entire API surface, a skill is a single procedure inside that surface.
- Standardized adapter shape. Every MCP server exposes the same tool-and-resource protocol; a skill is provider-authored prose with provider-defined trigger conditions. MCP is what you wire once; skills are what you author per workflow.
- Different audience. MCP servers are consumed primarily by MCP-compatible clients (Claude Desktop, Cursor, Cline, Continue, etc.). Skills are consumed by Claude specifically.
Three complementary surfaces
The network now indexes three formats that all answer some version of “how does an agent use this API”:
| Surface | Format | What it is |
|---|---|---|
| MCP server | Wire protocol | An adapter that exposes the API as structured tools any MCP client can call |
| Agent Skill | SKILL.md (frontmatter + prose) |
A provider-authored procedure with trigger conditions, loadable by Claude |
| Naftiko capability | YAML runtime spec | A portable spec that can be deployed as REST, MCP, or Agent Skill |
These aren’t competing — they’re complementary. The same provider often ships all three: an MCP server (wide adapter), a set of Skills (authored procedures for common workflows), and a Naftiko capability set (runtime spec backing both). Stripe is the clearest example of all three showing up on one provider profile, and you’ll see the cross-links to each surface there.
How this is wired
Both new sites follow the same network pattern as Industries and Regions:
- A taxonomy / inventory (for skills, the walked
SKILL.mdset; for MCP, theapis.ymlMCPServerentries) drives a deterministic extractor innetwork/scripts/build_skills.pyandbuild_mcp.py. - The extractor emits one detail page per artifact plus a per-provider rollup, and a summary YAML the apis.io hub uses for cross-network counts.
- The new sites publish the same agent-readiness baseline as the rest of the network:
llms.txt, RFC 9727api-catalogindirection via the master catalog, permissiverobots.txtwithContent-Signal: search=yes, ai-input=yes, ai-train=yes,Dataset/SoftwareApplicationJSON-LD per page, and lastmod-stamped sitemaps.
The extractors run at the end of every network build, so when the upstream provider mirror refreshes, both indexes refresh with it. The current count is a floor — as more providers add the AgentSkill and MCPServer property types to their APIs.json profiles, both sites grow on the next build.
Honest about coverage
A few things worth flagging:
- 10 of the 102 declared AgentSkill URLs go to unrelated repos.
github.com/github/Skills-Based-Volunteering-Publicis the most egregious — a CSR repo, not Agent Skills.box/box-skills-kit-nodejsis a content-analysis SDK from before the format existed.airbyte/airbyte-claude-skills404s. These will be fixed in the upstream provider profiles; the current index excludes them. - MCP coverage is more honest because the format has a single, well-known shape, and providers are putting their actual MCP server URLs in their APIs.json. Less mis-tagging than the skills side.
- Both indexes are derived from provider self-declaration. If a provider ships an Agent Skill or MCP server but hasn’t added it to their APIs.json, it doesn’t show up here yet. We pulled in
type: AgentSkillandtype: MCPServeras first-class property types specifically to fix this — the property is now part of the standard APIs.json vocabulary, and the network will accept it on every refresh.
What’s next
- Surface skills inside provider profiles. Right now you click out to skills.apis.io to see a provider’s skills. Next pass: a per-provider Skills section on the provider page itself, sibling to the existing Capabilities and Schemas sections.
- Index skill bodies for search. The detail-page bodies render fine, but the apis.io search index doesn’t read them yet. A skill is essentially a tiny RAG document; we should index the prose so an agent searching “how do I diagnose activation” can find the Amplitude skill body without going through the provider.
- Backfill the 10 bad URLs. Either find the canonical Agent Skill repo for each affected provider or remove the property cleanly.
- Lift the format-coverage stats. Cross-publish to the APIs.json and API Commons sites with a “how many providers ship X” tracker.
If you publish official Agent Skills or an MCP server for your API, the network will find them automatically once they’re declared in your APIs.json profile under api-evangelist. If your profile doesn’t exist yet, open an issue and we’ll get you in.