MCP Hub

14 min read

1. Overview

The MCP Hub is a centralized gateway that sits between MCP clients and MCP servers. It provides admins with full control over which MCP servers are accessible, which tools are exposed, and how they are packaged and delivered to consumers.

MCP clients connect to the hub — not directly to origin servers. The hub virtualizes, routes, and isolates all requests to the appropriate underlying MCP servers and their external APIs.

Supported MCP Clients

Any MCP-compatible client can connect to the hub, including but not limited to:

Unique AI (Unique)
Claude (Anthropic)
Copilot (Microsoft)
Gemini (Google)
Enterprise ChatGPT
Cursor
Custom MCP client

High-Level Architecture

~$05012026_MCPHub.pptxPowerPoint presentationDownload

Core Capabilities

Capability	Description	Category	Unique MCP Hub Version
Relay & Gateway	Acts as a managed relay between MCP clients and MCP servers. Clients never connect directly to origin servers.		Version 1
Virtual Servers	Combine tools from multiple origin servers into a single, repackaged MCP-compliant endpoint.		Version 1
Secure Credential Storage/ Isolation	Origin server credentials are stored securely and never exposed to MCP clients.	MCP Governance	Version 1
Server Acccess list	Two-layer access control (infrastructure + admin) with dual-approval for new servers.	MCP Governance	Version 1
Authentication	All clients authenticate via Zitadel (Unique IDP). A Unique account is required; the Unique UI is not.	MCP Governance	Version 1
Audit Logging	Comprehensive logging of all admin actions, access events, and tool invocations.	MCP Governance	Version 2
DLP Integration	Built-in data loss prevention with Microsoft DLP and custom DLP module support.	MCP Governance	Version 3
Tool Elicitation	Require explicit user approval before certain tools execute.		Version 3
Data Anonymization	Activatable data cleaning layer that anonymizes or scrubs sensitive data before it leaves the hub toward origin MCP servers.	MCP Governance	Version 4
Tool Configuration/ Filtering	Enable or disable individual tools from origin servers — fine-grained control over what is exposed.	MCP Server Management

2. Virtual Servers Version 1

A virtual server is a repackaged MCP-compliant endpoint that combines selected tools from one or more origin MCP servers. Admins create virtual servers by selecting which tools from which servers should be included, and which should be blocked.

How It Works

Admin selects one or more already-configured origin MCP servers from the catalog
For each origin server, admin enables/disables individual tools
The result is published as a new MCP endpoint (e.g., https://mcp.client-hostname.com/mcp/{name})
MCP clients connect to the virtual server endpoint — they have no awareness of the underlying origin servers

Example: Research Assistant Virtual Server

In this example, an admin creates a virtual server called "Research Assistant" that combines tools from Outlook and Confluence, but only exposes read/search capabilities:

From Outlook MCP Server:

Tool	Status	Reason
`search_emails`	ALLOWED	Users can search through emails
`create_draft`	ALLOWED	Users can create draft emails
`send_email`	BLOCKED	Sending not permitted in this context
`delete_email`	BLOCKED	Deletion not permitted
`list_folders`	BLOCKED	Not needed for research

From Confluence MCP Server:

Tool	Status	Reason
`search`	ALLOWED	Users can search for information
`get_page`	ALLOWED	Users can read page content
`create_page`	BLOCKED	No write access for research use case
`update_page`	BLOCKED	No write access for research use case
`delete_page`	BLOCKED	No write access for research use case

Resulting Virtual Server: "Research Assistant"

flowchart LR
    subgraph vs ["Virtual Server: Research Assistant\nEndpoint: /mcp/research-assistant"]
        direction TB
        subgraph exposed ["Exposed Tools"]
            T1["search_emails"]
            T2["create_draft"]
            T3["search_confluence"]
            T4["get_page"]
        end
    end

    subgraph outlook ["Outlook MCP Server"]
        OT1["search_emails"]
        OT2["create_draft"]
        OT3["send_email"]
        OT4["delete_email"]
    end

    subgraph confluence ["Confluence MCP Server"]
        CT1["search_confluence"]
        CT2["get_page"]
        CT3["create_page"]
        CT4["update_page"]
        CT5["delete_page"]
    end

    T1 -.->|allowed| OT1
    T2 -.->|allowed| OT2
    T3 -.->|allowed| CT1
    T4 -.->|allowed| CT2

Key Properties of Virtual Servers

MCP-compliant: Any standard MCP client can connect to a virtual server
Tool name uniqueness: When multiple origin servers have tools with the same name, the hub namespaces them (e.g., [Outlook] list_emails, [Gmail] list_emails)
Tool renaming: Admins can edit tool display names for broadcasting purposes
Dynamic path: Admins configure the virtual server's URL path
Static hostname: Platform admin configures the gateway hostname
Editable: Admins can add or remove servers and tools from existing virtual servers

3. Secure Credential Store Version 1

The MCP Hub maintains a secure, encrypted credential store for all origin MCP server connections.

Security Guarantees

Guarantee	Description
Never exposed to clients	MCP clients cannot see, access, or extract credentials of the underlying origin servers
Encrypted at rest	All credentials are stored with strong encryption
Scoped storage	Credentials are associated to the tuple: (origin server, virtual server, user)
Token mapping	The hub internally maps hub-issued tokens to the correct origin server credentials for each tool call
No credential passthrough	Clients authenticate against the hub only; the hub handles all downstream authentication

How Credential Flow Works

1. Client authenticates with MCP Hub (via Zitadel) ↓ 2. Hub issues a hub token to the client ↓ 3. Client calls a tool on a virtual server using the hub token ↓ 4. Hub resolves which origin server owns the tool ↓ 5. Hub retrieves the correct origin server credentials from the store ↓ 6. Hub calls the origin server with the stored credentials ↓ 7. Hub returns the result to the client (credentials never leave the hub)

4. Server Access List (Two-Layer Access Control) Version 1

Access to MCP servers is controlled through two independent layers. Both layers must grant access for a server to be reachable.

Layer 1: Infrastructure / DNS Level

An infrastructure administrator that deploys the MCP hub is responsible for defining the settings

Property	Description
Configured via	Environment variables
Format	RegEx patterns for allowed server URLs
Examples	`` (allow all), `.company.com` (allow company domain only), specific URL allowlist
Purpose	Controls which external URLs the hub is even permitted to connect to at the network level
Managed by	Infrastructure / platform admin

This is the first gate: if a server URL does not match the allowed patterns, the hub will refuse to connect to it regardless of admin configuration.

Layer 2: Admin Level

This Admin adds the servers and configures them for the end users.

Property	Description
Configured via	MCP Hub admin interface
Who	MCP Hub admins
Dual-approval required	Two admins must approve adding a new server
Purpose	Fine-grained control over which servers from the allowed URL list are actually configured and accessible

Version 2 Enhancement: Role-Based Server Management Version 2

In Version 1, all admin-level server operations are handled by a single admin role. In Version 2, admin responsibilities are split into two distinct roles to provide better separation of duties and tighter governance over the server catalog.

Role	Scope	Permissions
Server Admin (Adding Servers)	Controls which new origin MCP servers can be registered in the hub catalog	Register new servers, remove servers from catalog, configure server credentials, approve server additions (dual-approval)
Server Manager (Managing Servers)	Controls how already-registered servers are used within virtual servers	Assign servers to virtual servers, enable/disable tools, configure tool elicitation, manage virtual server endpoints

Why Two Roles?

Separating adding servers from managing servers ensures that:

The decision to onboard a new external MCP server (with its security, compliance, and data exposure implications) is made by a dedicated role with appropriate authority
Day-to-day configuration of virtual servers and tool selection can be delegated to operational managers without granting them the ability to introduce new external connections
Audit trails clearly distinguish who authorized a new server vs. who configured its usage

Version 1 vs. Version 2 Comparison

Aspect	Version 1	Version 2
Admin roles	Single admin role handles both adding and managing servers	Two distinct roles: Server Admin (adding) and Server Manager (managing)
Adding a new server	Any admin with dual-approval from another admin	Only Server Admins, with dual-approval from another Server Admin
Configuring virtual servers	Same admin role	Server Managers can configure virtual servers using servers already in the catalog
Infrastructure layer	Unchanged (env vars / RegEx allowlist)	Unchanged (env vars / RegEx allowlist)

5. Authentication Version 1

All MCP clients — whether Unique AI, Claude, Cursor, or any custom client — must authenticate through the MCP Hub via Zitadel, Unique's identity provider. The Downstream servers are autenticated directly towards the MCP Hub, the hub is then responsible for saving these tokens and keeping them secure.
Each user is taken throught the flow of the virtual server autenticating against all downstream servers and the hub is orchestrating this.

E.g: There is a virutal server with Outlook and Confluence tools in it.
The User autenticates a virtual MCP of the hub, must login via Zitadel into the hub, the user is then automatically taken to the downstream auth flows like Outlook via microsoft and Confluence via Atlasian. The tokens are securley stored on the hub only the Zitadel token is exposed to the clients.
Auth is then established.

Key Properties

Property	Description
IDP	Zitadel (Unique's identity provider)
Unique account required	Yes — a user must have a Unique user account
Unique UI required	No — any MCP client can connect; only the login flow goes through Zitadel
Hub token	Upon successful authentication, the hub issues its own token to the client
Credential mapping	The hub internally maps the hub token to the correct origin server credentials

6. Audit Logging Version 2

The MCP Hub provides comprehensive audit logging split into two categories: admin actions and access/usage events.

Admin Audit Logs (Always Active)

These logs capture all administrative changes to the hub configuration.

Logged Event	Details Captured
Server added	Who added it, server URL, server name, timestamp
Server deleted	Who deleted it, server details, timestamp
Server modified	Who modified it, diff of changes, timestamp
Virtual server created	Creator, name, endpoint URL, source servers, selected tools, timestamp
Virtual server edited	Diff of changes: servers or tools added/removed, tool renaming
Virtual server deleted	Who deleted it, virtual server details, timestamp
Tool permissions changed	Which tools, which virtual server, old/new state, who changed it
User access granted/revoked	Which user, which virtual server, granted by whom
Settings changed	Which setting, old value, new value, who changed it

Access / Usage Audit Logs (Activatable)

These logs can be activated to capture runtime access and usage events.

Logged Event	Details Captured
User authentication	User, authentication method, success/failure, timestamp
User authenticated on MultiLogin page	Per origin service (e.g. FactSet, Outlook, SEC Edgar), success/failure, timestamp
Virtual server accessed	User, virtual server, client type, timestamp
Tool invocation	Tool name, user, virtual server, resolved origin server, token used (masked), result OK/KO, timestamp
Query sent	User, virtual server, query content, timestamp
DLP decision	Request evaluated, tier that decided, allow/block, reason, timestamp
Data anonymization applied	Tool call, fields anonymized, rules applied, timestamp
OAuth token refreshed	Origin server, user, timestamp
OAuth token revoked	Origin server, user, who revoked, timestamp
Unauthorized tool call attempt	User, tool attempted, virtual server, reason for denial, timestamp
Elicitation event	User, tool, approved/rejected, modifications made, timestamp
External client connection	Non-Unique MCP client connected, client identifier, IP, timestamp

7. Unique Tools/Agents as an MCP Servers Version 2

Unique itself is treated as an MCP server within the hub. All of Unique's built-in capabilities are exposed as MCP tools and can be mixed into virtual servers alongside external MCP server tools.

Exposed Unique Tools

Category	Tools	Description
SWOT Analysis	SWOT analysis tools	Strategic analysis capabilities built into Unique
Internal Search	Internal search, knowledge base query	Search across Unique's internal data and knowledge base
Web Search	Web search tools	Search the web through Unique's web search integration
Deep Research	Deep reserach Tool	Execute a deep reserach
Sub-Agents	Configurable per deployment	Sub-agents defined in Unique are exposed as individual MCP tools

How It Works

Unique's capabilities are registered as an origin MCP server in the hub catalog, just like any external server. Admins can then:

Include Unique tools in any virtual server
Combine Unique tools with tools from external servers (e.g., Outlook + Unique web search)
Apply the same permissions, elicitation, and DLP rules to Unique tools as to any other tool

Example: Full-Service Virtual Server

A virtual server that combines external and Unique tools:

Tool	Origin
`search_emails`	Outlook MCP Server
`create_draft`	Outlook MCP Server
`search_confluence`	Confluence MCP Server
`web_search`	Unique MCP Server
`internal_search`	Unique MCP Server
`run_swot_analysis`	Unique MCP Server
`ask_compliance_agent`	Unique MCP Server (sub-agent)

8. DLP Integration (Data Loss Prevention) Version 3

The MCP Hub integrates a three-tier DLP architecture to evaluate all requests flowing through the hub. Every tool call can be inspected and approved or blocked before it reaches the origin server, and responses can be evaluated before being returned to the client.

DLP Architecture

Tier	Provider	Description
No DLP		DLP deactivated completely
Tier 1: Default Microsoft DLP	Microsoft	Activated by default with Unique-defined rules. Provides baseline data loss prevention out of the box with no additional configuration required. Default defined by Unique a rudametary config.
Tier 2: Extended Microsoft DLP	Microsoft	Easy connectivity to the client's own Microsoft DLP policies and configuration. Allows organizations to apply their existing DLP rules.
Tier 3: Custom DLP Modules	Third-party / Custom	Clients can add custom connectors to their own DLP servers. The hub sends the request to the custom DLP endpoint, which evaluates and returns allow/block.

DLP Request Flow

sequenceDiagram
    participant Client as MCP Client
    participant Hub as MCP Hub
    participant DLP as DLP Engine
    participant Origin as Origin MCP Server

    Client->>Hub: 1. Tool call request
    Hub->>DLP: 2. Evaluate request

    alt Allowed
        DLP-->>Hub: 3a. ALLOWED
        Hub->>Origin: 4. Forward tool call
        Origin-->>Hub: 5. Tool result
        Hub->>DLP: 6. Evaluate response
        DLP-->>Hub: 7. ALLOWED
        Hub-->>Client: 8. Tool result
    else Blocked
        DLP-->>Hub: 3b. BLOCKED (reason)
        Hub-->>Client: Request denied
    end

Key DLP Properties

DLP evaluation happens on both requests and responses
All three tiers are evaluated in sequence; a block at any tier stops the request
DLP decisions are written to the audit log (allow/block with reason)
Custom DLP modules are pluggable — clients provide the endpoint, the hub calls it

9. Permissions & Tool Elicitation VErsion 3

Permissions Model

The hub supports fine-grained permissions at multiple levels:

Level	Description
Virtual server access	Which users/groups are allowed to connect to which virtual servers
Tool-level access (Version 2)	Which tools within a virtual server are available to which users/groups (Version 2)
Tool elicitation	Which tools require explicit user confirmation before execution

Tool Elicitation

Elicitation is a mechanism where certain tools are flagged to require explicit user approval before the hub forwards the request to the origin server. The AI agent prepares the tool call, but the user must see and approve (or modify) it before execution.

Example 1: Sending an email via Outlook MCP

1. AI agent decides to send an email 2. Agent prepares the email (to, subject, body) 3. MCP Hub detects that "send_email" requires elicitation 4. Hub pauses execution and presents the prepared email to the user 5. User reviews the email content 6. User can: a) Approve → Hub forwards the tool call to Outlook MCP b) Modify → User edits the email, then approves c) Reject → Hub cancels the tool call

Example 2: Web search

1. AI agent decides to search the web 2. Agent prepares the search query 3. MCP Hub detects that "web_search" requires elicitation 4. Hub presents the intended search query to the user 5. User approves, modifies, or rejects the query

Configuration

Elicitation is configured per tool, per virtual server by the MCP admin. Any tool can be set to one of these modes:

Mode	Behavior
Auto-execute	Tool calls are forwarded immediately without user intervention
Elicit	Tool calls are paused; user must review and approve before execution

10. Data Anonymization & Cleaning Version 4

The MCP Hub includes an activatable data anonymization and cleaning layer that processes outbound data before it reaches origin MCP servers. This ensures that sensitive or personally identifiable information (PII) never leaves the hub boundary unless explicitly allowed.

This is off by default.

Purpose

External MCP servers are third-party systems that may not be under the organization's full control. When tool calls carry user data, conversation context, or query parameters to these servers, there is a risk of exposing sensitive information. The data anonymizer sits in the outbound path and scrubs or transforms data before it is forwarded.

How It Works

Activation & Configuration

The data anonymization layer is not active by default — it must be explicitly activated by an admin. Once activated, it can be configured at multiple levels:

Configuration Level	Description
Global (hub-wide)	Activate anonymization for all outbound traffic across all virtual servers
Per virtual server	Activate anonymization only for specific virtual servers
Per origin server	Activate anonymization only for traffic going to specific origin servers
Per tool	Activate anonymization only for specific tools (e.g., anonymize data sent to web search, but not to internal tools)

Anonymization Capabilities

Capability	Description	Example
PII detection	Automatically detect personally identifiable information in outbound payloads	Names, email addresses, phone numbers, social security numbers
Name replacement	Replace real names with pseudonyms or generic placeholders	"John Smith" becomes "[PERSON_1]"
Account/ID masking	Mask financial account numbers, employee IDs, and other identifiers	"CH93 0076 2011 6238 5295 7" becomes "CH93 XXXX XXXX XXXX XXXX X"
Email redaction	Redact or generalize email addresses	"john.smith@company.com" becomes "[EMAIL_REDACTED]"
Custom field removal	Remove specific fields or data patterns defined by the admin	Remove all fields matching a custom regex pattern
Contextual scrubbing	Scrub sensitive context from conversation data passed as part of tool parameters	Strip internal project names, client names, or confidential terms

Relationship to DLP

The data anonymizer and DLP are complementary but distinct:

Aspect	DLP	Data Anonymizer
Purpose	Block or allow requests based on policy	Transform data to remove sensitive content
Action	Binary: allow or block	Transformation: clean and forward
When it runs	DLP runs AFTER the anonymizer	Beofre the DLP, so it removes the sensitive data first so it passes through the DLP
Result	Request proceeds or is denied	Request proceeds with anonymized payload

Processing Order in the Hub Pipeline

1. Client sends tool call

↓

4. Elicitation check (if required for this tool)
↓ (if approved)
2. Data Anonymizer cleans the outbound payload (if activated)
↓

3. DLP evaluates the request (allow / block)
↓ (if allowed)
5. Hub forwards the cleaned request to the origin MCP server
↓
6. Response returns through the hub to the client

Audit Integration

All anonymization actions are logged:

Logged Event	Details
Anonymization applied	Tool call, virtual server, origin server, fields anonymized, anonymization rules applied, timestamp
Anonymization skipped	Tool call where anonymization was configured but no sensitive data was detected
Anonymization configuration changed	Admin changed anonymization settings, old/new config, timestamp

11. MCP UI Version 5

Status: Planned for Version 5

MCP UI is a capability that allows origin MCP servers to return rich UI elements (cards, forms, interactive components) that are passed through the hub and displayed inside MCP clients.

Planned Capabilities

Capability	Description
Card passthrough	Origin servers return structured UI cards; the hub passes them through to the client
Client rendering	MCP clients that support MCP UI render the cards natively
Fallback	Clients that do not support MCP UI receive a text-based fallback

This feature is not part of the initial release and will be specified in detail when Version 2 is planned.

Roadmap (preliminary)

Version	Target	Focus
VErsion 1	March 2026	Core platform: virtual servers, auth, credential store, access control
VErsion 2	April-May 2026	Audit logging and Unique tools/agents as MCP servers
VErsion 3	Q3 2026	DLP integration and granular permissions & tool elicitation
VErsion 4	Q4 2026	Data anonymization & PII cleaning layer
VErsion 5	2027	MCP Ul — rich card rendering and interactive components