APIs.io indexes MCP servers alongside OpenAPI, AsyncAPI, Postman, Arazzo, and the rest of the artifacts that describe an API. Discovery is one half of the problem — once someone finds your MCP server, they still have to install it, and right now that means you writing and maintaining a different set of instructions for every client: a JSON blob for Claude Desktop, a claude mcp add line for Claude Code, a deep link for Cursor, a per-OS config path for Windsurf and Zed, a connector walkthrough for the web clients. Nobody keeps all of that current.
The API Commons folks just shipped a fix, and it pairs naturally with an apis.io listing: MCP Install — the “Run in Postman” button, but for MCP servers. Configure your server once, get one button that installs it in every major and niche MCP client.
One button, every client
The button links to a hosted chooser that detects the visitor’s OS and renders the right install path for whatever client they’re using:
- One-click deep links where the client supports them — Cursor, VS Code, Visual Studio, LM Studio, Goose.
- Ready-to-run CLI commands where it doesn’t — Claude Code, Gemini CLI, Codex CLI.
- Per-OS config snippets for the config-file clients — Claude Desktop, Windsurf, Zed, Cline, Continue, Warp, Kiro, and more.
- Connector walkthroughs for the web clients — Claude, ChatGPT, Copilot coding agent.
Remote-only servers still reach stdio-only clients through an auto-generated mcp-remote bridge command, clearly labeled — so an HTTP server installs everywhere too.
Point it at a registry name
There are three ways to tell the button which server to install, and the first is the one we’d push for:
?name=io.github.acme/acme-mcp # an official MCP Registry name — installs stay current
?server=https://…/server.json # the URL of a manifest you host
?config=<base64url> # an inline definition, before a manifest exists
Carrying a pointer — a registry name or a server.json URL — instead of an inline config means the chooser resolves the definition from a canonical source and shows the user exactly what they’re installing. That’s the same discipline apis.io runs on: the definition lives in one authoritative place, and everything else references it.
APIs.io publishes its own MCP server (https://apis.io/mcp), registered as io.apis/apis-io. So the button for the catalog itself is just:
<script src="https://install.apicommons.org/button.js" async></script>
<mcp-install-button name="io.apis/apis-io"></mcp-install-button>
That’s the whole integration — a self-contained web component, no framework. You can limit which clients show, relabel it, switch to a light theme, or copy the button out as a plain link, Markdown, HTML, or a row of per-client deep-link badges from the generator.
The open registry underneath
What makes this work is clients.json — an open, machine-readable registry of how every MCP client installs a server: the deep-link builders, CLI templates, config paths per OS, and connector steps. It’s Apache-2.0, validated by a published schema, and adding a client is usually a pure data PR. Discovery on apis.io tells an agent a server exists; the registry tells any client how to install it.
One reminder if you publish a button: never put real secrets in it. Use <PLACEHOLDER> values for env vars and headers and let the client prompt the user or run OAuth. Nothing executes from the page — every output is a link the user’s client confirms or text they copy on purpose.
If you run an MCP server, give it a button and stop maintaining a dozen install READMEs by hand. And if it isn’t on apis.io yet, get it listed so agents can find it in the first place.
| Open MCP Install → | The apis.io MCP server → | The client registry → |