What is a virtual MCP server? Curating tools across MCP servers

#mcp #ai #devops #llm

TL;DR: A virtual MCP server combines tools from several real MCP servers into one curated server your app connects to. You pick only the safe tools, skip the destructive ones, and expose them as a single remote MCP server with no extra deployment. It is how you give an agent GitHub and Slack access without handing it delete_project.

As agents start calling live tools, the access question gets sharp fast. The Model Context Protocol (MCP) is great at connecting an AI agent to a data source or a set of tools, but a raw MCP server is usually all or nothing. You connect an agent to your GitHub MCP server and it can now see every tool that server exposes, including the ones that delete branches and close pull requests. A virtual MCP server fixes that by letting you hand an agent a curated subset of tools drawn from one or more underlying servers, without standing up anything new.

This guide covers what a virtual MCP server is, how it works, how tool naming is handled, and where it fits inside a broader MCP gateway.

What is a virtual MCP server?

A virtual MCP server combines tools from multiple MCP servers into a single, curated MCP server that your application connects to. Instead of pointing an agent at each backend server directly, you assemble the exact set of tools you want it to have and publish that set as one server.

The example TrueFoundry uses in its docs makes it concrete. Say you have MCP servers for GitHub and Slack registered on the gateway. A team building an agent needs access to both, but you do not want to expose tools like delete_project or delete_pr. With a virtual MCP server, you create a new server that takes only the safe subset from GitHub and Slack. That new server is reachable like any other remote MCP server, and it does not require a deployment. The gateway manages it.

The practical win is least privilege for agents. You decide what an agent can touch at the tool level, not the server level.

A virtual MCP server works well when:

An agent needs tools from more than one backend, but not all of them.
You want to strip destructive or high-risk tools before an agent ever sees them.
Different teams or applications need different slices of the same underlying servers.
You want to scope tool access without deploying or maintaining a bespoke proxy server.

How a virtual MCP server works

The flow is straightforward once the underlying servers are registered on your MCP gateway.

Register your real MCP servers. Connect the backends you want to draw from, for example GitHub and Slack, to the gateway.
Select the safe tools. Pick the subset of tools from those servers that the agent should have. Leave out anything destructive or out of scope.
Publish the virtual server. The gateway exposes your selected tools as a single virtual MCP server. There is no separate deployment to run or scale, since the gateway hosts it.
Connect your app. Point your agent or MCP client at the virtual server the same way you would any remote MCP server, over streamable HTTP.

From the agent's side, it just sees one clean server with a sensible set of tools. All the curation happens at the gateway.

How tool names are handled

When you pull tools from several servers into one virtual server, name collisions are a real risk. Two backends can both expose a create_issue, for instance. TrueFoundry handles this by keeping each tool's original name and appending a short random suffix, so create_issue becomes something like create_issue_a1b2c3. The suffix keeps every tool unique within the virtual server.

Worth noting why it is done this way rather than prefixing with the server name (like github-create_issue). The MCP spec recommends keeping tool names within 64 characters, and a long server name can eat most of that budget. Since the tool name is the strongest signal an LLM uses when deciding which tool to call, preserving it in full while adding a short suffix keeps names both meaningful and collision-free.

Virtual MCP server vs a raw MCP server

Aspect	Raw MCP server	Virtual MCP server
Tool scope	All tools the server exposes	Curated subset you choose
Sources	One backend	One or more backends combined
Access control	Server-level, all or nothing	Tool-level, least privilege
Deployment	You run and manage the server	Managed by the gateway, no deployment
Best fit	Full trusted access	Scoped access per team, app, or workflow

The two are not competitors. A virtual MCP server sits on top of your real servers and gives you a governance layer over them.

Where virtual MCP servers fit in the MCP gateway

A virtual MCP server is one feature of a larger job: giving enterprise agents governed access to tools. On its own, MCP adoption tends to sprawl. Every developer wires up their own server connections in Cursor, VS Code, or Claude Code, credentials scatter across machines, and security teams get no visibility into which tools are being called or by whom.

An MCP gateway centralizes that. The TrueFoundry MCP Gateway gives AI agents a single point of access to many MCP servers, with a few capabilities that make virtual servers more useful in production:

Standard OAuth flows. Agents and developers authenticate through standard OAuth 2LO and 3LO flows for enterprise MCP servers, instead of ad-hoc keys per tool.
Governed, tool-level access. Access control is enforced centrally, which is what makes the curated tool subset in a virtual server meaningful rather than cosmetic.
Pre-tool and post-tool guardrails. You can run checks before and after a tool call to enforce policy, so a curated tool set can also be a guarded one.
Full audit trail and metrics. Every tool call is visible, with request rates, latency, failures, and usage patterns per server and per tool.
More ways to build servers. Beyond curating existing servers, the gateway can turn an OpenAPI spec into MCP tools and run CLI-style stdio servers as managed, hosted endpoints.

If you need to pass custom credentials through to the backends behind a virtual server, the gateway supports an x-tfy-mcp-headers header that forwards per-server headers to the underlying MCP servers. One current limitation to keep in mind: virtual MCP servers today support listing and calling tools, so plan around that if you rely on other MCP features.

When to use a virtual MCP server

Reach for a virtual MCP server when tool access needs to be scoped rather than wholesale. A few common cases:

Least-privilege agents. Give an agent exactly the tools its task needs and nothing that can cause damage.
Per-team or per-app tool sets. Publish different curated servers for different consumers off the same backends.
Multi-tenant tool catalogs. Offer curated, discoverable tool sets to different tenants without exposing raw servers.