Skip to main content

What is Virtual MCP Server?

The Virtual MCP Server enables you to combine tools from multiple MCP servers into a single, curated MCP server that your application can connect to. Virtual MCP Server Suppose you have integrated MCP servers for GitHub and Slack on TrueFoundry. A team in your company is working on an Agent that requires access to these two MCP servers. But you do not want to expose tools like delete_project, delete_pr, etc. As the name suggests, Virtual MCP Server allows you to create a new MCP server by taking a subset of safe tools from GitHub and Slack MCP servers. This new Virtual MCP server can be accessed like any other remote MCP server and does not require a deployment.

How to create a Virtual MCP Server?

When you create or edit a Virtual MCP Server, set Name as the unique identifier (used in URLs and API references) and optionally set Display Name. Display Name is the human-readable label shown throughout the MCP registry — including the MCP servers page and the tool selector — instead of the internal name. If you omit it, Name is shown.

How are tool names decided?

Tools keep their original name with a short suffix: <original_tool_name>_<suffix>. That keeps names unique across source servers while preserving the original name for the LLM. By default, the suffix is the first 5 characters of the source server’s name plus the last 2 characters of its ID (for example, create_issue from github → create_issue_githua3). Optionally set Tool Slug on a source (or tool_slug in the manifest) to use your own suffix instead — for example, github → create_issue_github. Sources without a slug keep the auto-generated suffix. Tool Slug must be 1–16 lowercase letters, digits, or hyphens, and unique across sources in the virtual server (including auto-generated suffixes). Full tool names are limited to 64 characters; longer original names are truncated to fit the suffix.

Connecting to source servers

You don’t need to sign in to every source server upfront. Connect now, or wait until a tool first needs it.

Choose when to connect

  • When you connect a client, the consent page lists each source server with Connect now (default) or When needed.
  • A source must be connected now if:
    • Its tools aren’t cached yet.
    • A tool call is waiting for you to sign in to it.
The Connect via TrueFoundry Gateway consent page listing two servers with cached tools, each with Connect now and When needed options, plus Deny and Approve buttons

Pick Connect now or When needed for each source server

Tools from unconnected sources

  • Tools from sources you haven’t connected to are listed from cache.
  • The Tools tab marks them Cached and shows a Connect button on each tool.
  • If a source has no cached tools yet, connecting to the virtual server asks you to sign in to that source.
The Tools tab of a virtual MCP server showing a Some Tools Are Cached banner. Hugging Face and Linear tools are labeled Cached with a Connect button, while connected GitHub tools show a Try button

Cached tools from unconnected sources, each with a Connect button

Sign in from a tool call

Calling a tool from an unconnected source doesn’t fail. The tool returns a sign-in link that your agent shows in chat:
Open the link to connect only that source. The agent then retries the tool call.
The Connect via TrueFoundry Gateway consent page showing a source server under Connection required, labeled A tool call is waiting for your sign-in, with Deny and Approve buttons

The sign-in link opens the consent page with the waiting source marked as required

Best Effort Mode

By default, if any source MCP server backing the virtual server is unreachable or fails (for example, while listing tools), requests to the virtual server fail as a whole. Enabling the Best Effort Mode toggle when creating or editing the virtual server changes this behavior: the virtual server continues with the source servers that are available, so clients still get tools from the healthy servers, while tools from the failed servers are simply unavailable until those servers recover. The toggle is off by default. Best Effort Mode only covers sources that fail. Sources you haven’t connected to are handled as described in Connecting to source servers, whether the toggle is on or off.

Frequently Asked Questions

You can use x-tfy-mcp-headers to pass custom headers, which will be passed to the remote MCP servers backing the virtual server.For MCP Gateway (direct MCP server access):
The Virtual MCP server is managed by the MCP Gateway and does not require a new deployment.
For now, only listing and calling tools are allowed. Progress notifications that a backing server sends during a tool call are relayed to your client when the request includes a progressToken. See MCP Protocol Support for the full feature and transport matrix.
Each tool’s _meta includes truefoundry.com/sourceServer, the source server it came from. Sources that were skipped while listing tools appear in truefoundry.com/failedSources, each with a reason.