A remote MCP server behind the firewall

"Behind the firewall" means the MCP server process and the systems it reads stay inside your network boundary, and only what a tool returns travels out. The model stays outside, at its provider, and never touches the network. What matters is what each tool call sends across the line, and who was allowed to make the call.

Three places the server can run

• The vendor's cloud. The server runs on the vendor's infrastructure and reaches your systems through credentials you give it. Fastest to start; your data leaves on every call.
• Your cloud account. The server runs in your VPC. Internal databases are reachable without exposing them, and the model provider still only sees tool results.
• Your own network. The server runs on premises. Same properties as the VPC, plus the firewall rules you already have.

In the second and third cases the client is still outside: an employee's laptop running Claude Desktop, or a hosted agent. So the endpoint must be reachable from the client, through a reverse proxy, a VPN or an allowlist, and it must authenticate every request.

What leaves the network on a tool call

Three things cross the boundary on a normal remote connection.

1. The tool list. Names, descriptions and input schemas go to the client and on to the model. Descriptions are prompt text. Keep secrets and internal hostnames out of them.
2. The arguments. The model chooses them, so they arrive from outside and need the same validation as user input.
3. The result. Whatever your tool returns goes to the client and into the model's context, at the model provider. This is the payload the firewall discussion is about. A tool that returns one customer's record sends one record out. A tool that returns the whole table sends the table.

The result is where the data flow is decided. Return the fields the task needs, cap row counts, and keep raw query access off the tool list.

Authentication and scopes

The MCP specification uses OAuth 2.1 for HTTP transports. The server advertises its authorization server through protected resource metadata, the client obtains a token for that server specifically, and every request carries it as a bearer token. Tokens issued for another server must be refused. The server can name the scopes a request needs in its 401 or 403 response, and the client asks for exactly those. For an enterprise this means the MCP server can sit behind the same identity provider as everything else, and the person approving in the browser is a known account rather than a shared API key.

Scopes decide what a token may do. The tool list decides what the model can even attempt. Both narrow the surface, and neither replaces the checks inside each tool.

What OBTO offers today

OBTO's MCP server runs on OBTO's cloud at https://app.obto.co/ms/mcp. Sign-in is OAuth with a Google account, and the catalog a session receives follows the identity that signed in. A tenant can publish its own tools, resources and prompts, and a second endpoint form, ?scope=tenant, serves a connection only those, plus the identity tool. That is a catalog filter for a tenant's users; every tool still runs its own checks when called. Every tool call writes a usage row per day, per app and per tool, so there is a count of calls and errors to read after the fact.

For a server inside your own boundary, the Enterprise plan offers bring-your-own models and self-hosting by separate agreement. There is no download to run on the standard plans, and no private network peering. If your requirement is "the server runs in our VPC on day one", say so in the first conversation and the answer will be about the Enterprise path or about a different tool. MCP server as a service describes the hosted path in full, and hosting a remote MCP server covers running your own.