Ricardo Rodrigues

Posted on Apr 22

MCPNest Gateway — One URL to Rule All Your MCP Servers

#ai #mcp #claude #cursor

MCPNest v1.11 | April 2026

The MCP ecosystem has a governance problem.

Developers are installing MCP servers directly into Claude Desktop and Cursor — GitHub integrations, database connectors, web scrapers, API wrappers. The tools are good. The problem is that nobody in IT knows which ones are running, who installed them, or what they're doing.

This is the problem the MCPNest Gateway solves.

The Problem With How Teams Use MCP Today

When a developer wants to add an MCP server to their Claude Desktop setup, they edit a JSON file:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_..." }
    }
  }
}

This works fine for one developer. It falls apart for a team.

There is no central list of which servers are approved. No versioning — if a server updates and breaks something, there is no rollback. No audit trail — if Claude connects to an external system and something goes wrong, there is no record of what happened. And no access control — any developer can add any server without approval.

For individual developers, none of this matters. For a team of 20 at a company that cares about security, it is a governance gap.

What the Gateway Does

The MCPNest Gateway gives each Enterprise workspace a single authenticated endpoint:

https://mcpnest.io/api/gw/{workspace-slug}
Authorization: Bearer mng_...

Instead of each developer maintaining their own JSON config with multiple servers, they point Claude Desktop or Cursor at this one URL. The Gateway handles everything else.

tools/list — When Claude asks what tools are available, the Gateway calls tools/list on every server approved in the workspace, aggregates the results, and returns a unified list. From Claude's perspective, it is talking to one server. Behind the scenes, it might be five.

tools/call — When Claude calls a tool, the Gateway identifies which server owns that tool and proxies the request. The developer does not need to configure anything. The routing is automatic.

Logging — Every tool call is logged at the protocol level: which tool was called, on which server, with what status code, and how long it took. No input or output content is stored — only metadata. GDPR-safe by design.

The Architecture

The Gateway is built on three files.

auth.ts handles token verification. Bearer tokens are stored as SHA-256 hashes — never in plaintext. Comparison uses timingSafeEqual to prevent timing attacks. Tokens use a mng_ prefix so they are immediately recognisable in logs and distinguishable from other API tokens.

logging.ts handles fire-and-forget writes to mcp_tool_calls. If the table does not exist or the write fails, the proxy continues — logging never blocks a tool call.

route.ts handles the actual proxying. It resolves the workspace, verifies the token, parses the JSON-RPC body, fetches tools from each upstream server, and routes calls to the correct endpoint. It supports both JSON and SSE transport — auto-detecting from the response content-type header — because different MCP servers use different transports.

The database schema is straightforward:

gateway_workspaces — one row per workspace, with the token hash and plan
gateway_workspace_servers — which servers each workspace exposes, with position ordering and optional tool prefix to avoid name collisions
mcp_tool_calls — append-only log of every tool call, retained for 90 days

What Gets Logged

Each row in mcp_tool_calls contains:

workspace_id — which workspace made the call
server_slug — which upstream server handled it
tool_name — which tool was called
status — HTTP-style status code (200 for success, 4xx for client errors, 5xx for upstream errors)
latency_ms — how long the round trip took
created_at — timestamp

Nothing from the input parameters or output content is stored. The log answers "what happened" without storing "what was said."

A Real Test

After deploying, I tested with a workspace containing the Context7 MCP server (documentation lookup) at https://mcp.context7.com/mcp.

curl -s -X POST https://mcpnest.io/api/gw/bcp-test \
  -H "Authorization: Bearer mng_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "resolve-library-id", "description": "..." },
      { "name": "query-docs", "description": "..." }
    ]
  }
}

Two tools returned, proxied through the Gateway, logged in mcp_tool_calls. Latency around 1000ms — the Gateway adds minimal overhead on top of the upstream server response time.

The Supabase log confirmed 5 calls, all status 200, latencies between 821ms and 1440ms.

What This Means for Enterprise Teams

The question most IT teams ask when developers start using AI tools is: "What is Claude actually connecting to?"

Without the Gateway, the answer is "we don't know." Each developer has their own config. Servers come and go. There is no central record.

With the Gateway, the answer is: every tool call is in mcp_tool_calls. IT controls which servers are in the workspace. Developers cannot add servers without admin approval. Every action has a timestamp and an owner.

It is the same principle as an API gateway like Kong or AWS API Gateway, applied to the MCP protocol.

Current Limitations

The Gateway v0 works with MCP servers that have a remote HTTP endpoint. Local servers — those that run via npx or node on the developer's machine — cannot be proxied because they have no public endpoint to route to. This covers a significant portion of the MCP ecosystem today.

Servers that require authentication (like RailPush, which needs a Bearer token) need their credentials configured in the workspace config_override. There is no UI for this yet — it requires a direct database insert.

There is also no workspace creation UI yet. Workspaces are created via SQL. This is the next thing to build.

What Comes Next

The immediate next step is a workspace creation UI — a page where Enterprise users can create a workspace, add servers, generate a Bearer token, and copy the Gateway URL. Right now all of this requires direct database access.

After that: token rotation UI, per-server health status in the Gateway response, and rate limiting per workspace.

The longer-term goal is making the Gateway the standard way teams distribute MCP server access — the same way Artifactory or a private npm registry distributes packages, but for MCP servers.

MCPNest is a marketplace and governance layer for MCP servers. 7,561+ servers indexed. Gateway live since April 20, 2026. Free to use at mcpnest.io — Enterprise for teams.

Tags: MCP, Model Context Protocol, TypeScript, Claude, Enterprise AI, API Gateway, Developer Tools

DEV Community