Virtual Servers — Unique AI Documentation
Virtual Servers
What A Virtual Server Is
A virtual server is a curated MCP endpoint that AI clients connect to. It is composed by selecting tools from one or more origin MCP servers already registered in the catalog, then publishing the result under a stable URL on the gateway.
Clients see a single MCP server. Behind the scenes the hub routes each tool call to the correct origin, applies the user's downstream credentials, and enforces the permissions configured for the virtual server.
Curated tool set. Only the tools selected from approved origins are exposed. Disabled tools are not reachable through the endpoint.
Stable endpoint URL. The URL is composed of the gateway hostname and an admin-defined slug. It does not change when origins are reorganized.
Lifecycle. A virtual server can be disabled at any time. While disabled it is not reachable for MCP clients.
Multi-origin composition. A single virtual server can combine tools from several origin servers, presented under one consistent namespace.
Why Use A Virtual Server
A virtual server is the mechanism that turns a collection of approved connectors into something a team, a product, or an AI client can actually use. Without one, origin capabilities sit in the catalog but are not reachable from outside the platform.
Connect any MCP-compatible client. Publish one stable URL and any client — Claude, Copilot, ChatGPT Enterprise, Cursor, Gemini, or a custom assistant — can connect without bespoke integration work per system.
Compose across systems. Bundle tools from Outlook, Confluence, Salesforce, FactSet, and internal APIs into a single endpoint. The user's AI assistant sees one coherent tool surface, not a fragmented list of separate servers.
Enforce least privilege by design. Expose only the tools a specific audience needs. A research team gets search and read tools; a sales team gets CRM read and email draft; neither sees the other's capabilities.
Isolate credentials and identities. Every tool call runs under the end user's downstream credentials, injected server-side by the hub. Clients never hold origin secrets, and cross-user credential leakage is structurally prevented.
Stay in control as usage grows. Disable a virtual server instantly if its scope changes or an incident occurs. Add or remove tools at any time without touching the endpoint URL or reconfiguring connected clients.
Reuse without reprovisioning. New use cases draw from connectors already approved in the catalog. Creating a second virtual server for a new team or workflow takes minutes and requires no new infrastructure.
Build a foundation for governance. The virtual server is the policy and audit point. Tool-call logging, future DLP inspection, anonymization, and elicitation all apply at this layer — enabling richer controls as they mature.
Anatomy Of A Virtual Server
| Element | Description |
|---|---|
| Name | Human-readable label shown in the admin app and in tooling that surfaces the virtual server. |
| Endpoint URL | Composed of the gateway hostname and an admin-defined slug, e.g. https://gateway.{tenant}.unique.app/mcp-hub/{slug}/mcp. |
| Description | Optional short description that helps administrators and end users understand the intent of this virtual server. |
| Tools | The set of tools imported from registered origin servers. Each tool can be toggled individually. |
| Enabled state | When enabled, the endpoint is reachable. When disabled, traffic is rejected and the endpoint is not discoverable. |
Create A Virtual Server
The full create flow lives in the Connectors workspace in the Unique admin app.
1. Open the create dialog
Open Add an MCP connector and choose Create a virtual server.
2. Set name, endpoint URL, and description
The endpoint URL is composed of the gateway hostname plus a slug that you control. The slug is auto-suggested from the name and can be overridden. The full URL is what MCP clients will connect to once the virtual server is enabled.
3. Add tools from approved origins
A new virtual server has no tools and is disabled. Open Add Tools to select capabilities from one or more origin MCP servers that are already registered in the catalog.
4. Enable and share
Once the tool set is correct, switch the virtual server to Enabled. The endpoint URL becomes reachable for MCP clients. Use Share to manage access and copy the endpoint URL for distribution.
Lifecycle
Draft. The virtual server exists but is disabled. Administrators can adjust the name, description, slug, and tool set without affecting any clients.
Enabled. The endpoint URL is reachable for MCP clients. Tool calls are routed to the configured origins.
Disabled. The administrator switches the toggle off. The endpoint is no longer reachable and the virtual server is hidden from clients.
Updated. Tools can be added or removed at any time. Clients see the updated tool set on the next list refresh.
End-to-End Flow
Approve origins. An administrator registers origin MCP servers, reviews OAuth metadata, and makes tools available in the catalog.
Curate a virtual server. Tools are selected across one or more origins. The endpoint stays in draft until it is ready.
Publish one URL. The hub exposes a stable MCP URL such as
https://gateway.example.com/mcp-hub/research/mcp.Connect an MCP client. The user signs in, completes downstream logins when needed, and calls approved tools through the hub.
Recommended Practices
Use a clear, stable slug. The slug appears in the endpoint URL and should not change after distribution.
Keep virtual servers narrow. Multiple focused virtual servers are easier to govern than one broad endpoint.
Start with read-only tools for new use cases. Add write or send tools only after access and monitoring expectations are clear.
Document the intended audience in the description so other administrators understand the purpose.
Disable a virtual server immediately if its tool set becomes uncertain. Disabling is reversible; deleting is not.