Clients & CLI
How the main clients connect to MCP (each linked to its own docs), plus catalogue entries matched by CLI text. No server-by-client support matrix - we do not have that data.
How the clients connect to MCP
One line per client on how it connects (stdio or HTTP), each linking to its own official documentation. There is no per-server support claim here - we do not have that data.
| Client | How it connects | Official docs | We checked it on |
|---|---|---|---|
| Claude Desktop | Local servers go into mcpServers in claude_desktop_config.json (a command, stdio); remote servers are added as Connectors over HTTP. | modelcontextprotocol.io/docs/develop/connect-local-servers ↗ | 2026-10-20 |
| Claude Code | claude mcp add on the command line: --transport stdio (default) runs a local command, --transport http <url> connects a remote endpoint. | code.claude.com/docs/en/mcp ↗ | 2026-10-20 |
| Cursor | The mcpServers block in mcp.json: command starts a local server (stdio), or a url connects an SSE / Streamable HTTP endpoint. | cursor.com/docs/mcp ↗ | 2026-10-20 |
| VS Code | The servers block in .vscode/mcp.json (or the user-level mcp.json): Command (stdio) for a launch command, HTTP for a remote endpoint URL. | code.visualstudio.com/docs/agent-customization/mcp-servers ↗ | 2026-10-20 |
| Codex | [mcp_servers.<name>] tables in ~/.codex/config.toml: command starts a local process (STDIO), url connects Streamable HTTP. | developers.openai.com/codex/mcp/ ↗ | 2026-10-20 |
Entries related to the CLI / command line
Matched by name or description containing CLI / command line: 428 entries. This is a text match, not an official label, and not hand-confirmed.
Common questions about this page
How were these 428 CLI entries selected?
A whole-word text match over name, one-line summary, original description and field tags (cli / command line). It is a text match, not an official label, and nothing was confirmed by hand: a project may say CLI and still be a library, and a server that ships a CLI without the word in its description will not appear. The count is recomputed from the database on every rebuild.
Why is there no server-by-client support matrix?
Because the database has no such field and no source provides one. Filling that matrix would mean guessing, and a guessed cell is worse than an empty one. The client half lists how each client connects generally, with a link to its own documentation.
How often is the client half re-checked?
Each row prints the date we checked it: 2026-10-20, opened one by one, HTTP 200, with the stdio / HTTP connection described in the document itself. Documentation changes; the link is the current source of truth.
How do you tell local servers from remote ones?
By evidence, not by name: whether the official MCP Registry records a remote endpoint for the repository, whether the entry URL is itself an endpoint, and whether the install command is a command or a URL. What we cannot establish we leave unlabelled, and the coverage numbers are printed on the Remote servers page.
How do I use one of these entries?
Open its detail page: source link, when we last saw it, and a confirmed install command where one exists (when it could not be confirmed, the page says so rather than printing a command that will fail).
What we actually check
Two kinds of information here: (1) how each client connects comes from that client's own documentation, opened and checked row by row (the date is in the table); (2) the CLI entries are a whole-word text match over names and descriptions, not an official label and not hand-confirmed. The database has no "which server supports which client" data, so there is no such matrix here - it would look good and it would be invented.
Found something missing or wrong?
Tell us and we re-check it against the source before it changes.
Contact us ↗