There are two shapes. A local server is a command the client launches as a subprocess, configured with a command, its arguments and any environment variables it needs. A remote server is a URL you point the client at, usually followed by a browser sign in. Your client's own documentation is the authority on where that configuration lives.
The client starts the server as a child process and talks to it over standard input and output. Nothing listens on a port and nothing crosses the network. The configuration is a name, a command, its arguments, and the environment the process needs.
{
"mcpServers": {
"some-gtm-tool": {
"command": "npx",
"args": ["-y", "@vendor/mcp-server"],
"env": { "VENDOR_API_KEY": "the key you generated in the vendor dashboard" }
}
}
}Three details that matter. The name is yours and appears in the client. The command has to be on the path the client uses, which is often not the path your shell uses. And the environment block is where credentials go: they live in a file on your machine, in plain text, so treat that file the way you would treat any other file holding an API key.
You give the client a URL, it connects over HTTP, and auth is usually a browser sign in that hands back a scoped token. Nothing is installed and the vendor ships updates without you. Of the 165 servers counted here, the OAuth ones are almost all this shape.
Every tool page here prints the vendor's mcp_url and mcp_auth verbatim, exactly as recorded, plus a link to the vendor's own documentation where one is published. 174 entries carry a parseable URL and 30 carry a documentation URL. No install snippet is reproduced anywhere on this site, because a snippet copied from a directory is a snippet that goes stale without anybody noticing.
Every number on this page is generated from directory.json at build time and carries the date it was baked: 2026-08-25. Nothing is typed by hand, nothing is rounded, and nothing is estimated. The underlying data is published in full. Where the honest answer is a zero, the zero is printed.