Access types
Beta — the MCP Gateway is open source and on npm:
npx -y @mcp-rating/gateway. Source →
MCP servers are distributed in different ways, and the Gateway connects to each with the controls that apply to it. The MCP Rating registry classifies every server by access method, so you know what you're getting before you connect.
Local servers
Spawned on your machine:
| Access method | Runs as | Needs installed | Controls |
|---|---|---|---|
npm (npx) |
Node package | Node.js | L1 env scoping; L2 container if enabled |
PyPI (uvx) |
Python package | uv | L1 env scoping; L2 container if enabled |
Docker (docker run) |
Container image | Docker | Its own container, with whatever flags its install command sets |
If the launcher isn't installed, the connect fails and names what to install. The Gateway never substitutes a package of the same name. See sandboxing for what each level does and doesn't restrict.
Remote / web servers
Connected over the network via an MCP URL:
| Access method | Runs as | Controls |
|---|---|---|
| Remote (SSE / streamable HTTP) | Hosted by the provider | Connection policy + audit logging |
Container sandboxing doesn't apply: the server runs on the provider's infrastructure, not yours. Its tool calls still go through your permission policy and into the audit trail; resource reads and prompts are passed through unrecorded.
Why it matters
A remote server and a local npm package carry very different risks. The registry's access-method labels, plus the Gateway's per-type controls, let you choose and run each appropriately.