The Model Context Protocol (MCP) is an interface specification that allows a Language Model (LLM) to discover, understand, and invoke external capabilities, often referred to as tools. A tool is a defined function or service, complete with a descriptive schema, that an agent an autonomous system utilizing an LLM can choose to call to execute a task.
While running MCP servers locally is straightforward, deploying them reliably and securely for large-scale or multi-tenant agentic workflows presents significant challenges 1. Enterprises require centralized control over access, transport, and, most importantly, the specific capabilities exposed to different agents. The emergence of managed MCP proxy services, built on resilient cloud architecture, directly address…
The Model Context Protocol (MCP) is an interface specification that allows a Language Model (LLM) to discover, understand, and invoke external capabilities, often referred to as tools. A tool is a defined function or service, complete with a descriptive schema, that an agent an autonomous system utilizing an LLM can choose to call to execute a task.
While running MCP servers locally is straightforward, deploying them reliably and securely for large-scale or multi-tenant agentic workflows presents significant challenges 1. Enterprises require centralized control over access, transport, and, most importantly, the specific capabilities exposed to different agents. The emergence of managed MCP proxy services, built on resilient cloud architecture, directly addresses this operational gap.
Selective Tool Access and the Virtual MCP
A core challenge in deploying complex agentic systems is the management of tool complexity and scope. As agents integrate with multiple services (e.g., Notion, Neo4j, ticketing systems), the total number of available tools can rapidly grow, confusing smaller, context-limited models and increasing the cognitive load within the LLM’s context window 2. Furthermore, enterprise applications demand strict governance, ensuring that development agents do not wield destructive capabilities in a production environment.
The solution presented by advanced proxy architectures is the Virtual MCP. This feature allows a developer to define a single, logical MCP endpoint that transparently aggregates tools from several underlying physical MCP servers while applying a layer of fine-grained access control.
The fundamental process involves two steps: aggregation and filtering 1. A developer selects multiple source MCPs (e.g., a Notion MCP and a Neo4j MCP). They then selectively prune the capabilities exposed through the new Virtual MCP endpoint.
For example, a production-focused Virtual MCP could be configured to remove all destructive methods (delete, create, update, drop_table) while retaining read-only capabilities (read_incident, query_graph). This control is managed centrally at the proxy layer, independent of the underlying MCP server code. As demonstrated in the talk, a single agent could successfully query both a Notion database and a Neo4j graph through one unified endpoint, with only read actions permitted, enhancing both safety and agent efficiency.
Conceptual Virtual MCP Schema
{ "virtual_mcp_id": "prod_read_only_data_access", "base_url": "https://mcp-cloud.ai/v1/virtual/prod_read_only_data_access", "source_mcps": [ { "mcp_server_name": "notion_v2_incident_db", "tools_to_include": [ "notion_get_incidents", "notion_search_pages" ], "tools_to_exclude": [ "notion_create_comment", "notion_delete_page" ] }, { "mcp_server_name": "neo4j_graph_analytics", "tools_to_include": [ "neo4j_run_readonly_query" ], "tools_to_exclude": [ "neo4j_execute_write", "neo4j_delete_nodes" ] } ], "authentication_scope": "read_only_service_token" }
Secure Hosting and Multi-Protocol Agnosticism
Beyond logical tool management, the physical hosting environment must be secure, reliable, and flexible regarding transport protocols. MCP-cloud.ai initially focuses on providing a secure, authenticated Software-as-a-Service (SaaS) platform for one-click deployment of pre-tested MCP servers.
The platform’s architectural shift was driven by the need for more specialized features, leading to the development of a custom infrastructure stack centered on a Kubernetes Operator and a specialized Proxy.
Transport Agnosticism: Different MCP servers may use various protocols (e.g., streamable HTTP, Server-Sent Events, or the deprecated SEC transport). The custom proxy acts as a translation layer, allowing agents to communicate with a unified HTTP endpoint regardless of the underlying server’s required transport. This provides crucial backward compatibility and forwards flexibility without forcing developers to redeploy servers to change communication methods. 1.
Automated Security Assessment: For enterprises, a significant barrier to adoption is vetting third-party MCPs. The platform addresses this with an automatic security assessment capability. This system uses built-in heuristics and comparisons against a database of known vulnerabilities, similar to a CVE process 1. This scanning is a necessary precursor to allowing users to integrate their own, unvetted "Bring Your Own MCP" (BYOMCP) servers, ensuring that any deployed capability meets a minimum security threshold before being exposed to agents. 1.
Cost-Efficient Scaling: The architecture leverages Kubernetes to manage resources. The operator enables customizable authentication and, critically, allows for the automatic scale-down of MCP server pods when they are no longer actively connected. This dynamic scaling saves operational costs for both the platform and its users.
Behind the Scenes / How It Works: The Custom Kubernetes Operator
The platform’s ability to offer both flexibility and security stems from its decision to move away from generic, off-the-shelf cloud infrastructure towards a custom-built solution based on the Kubernetes Operator pattern 4.
The Role of the Kubernetes Operator: The Operator is a specialized software component running inside the managed Kubernetes cluster. Its function is to automate the deployment, management, and scaling of the MCP servers. When a user requests to deploy an MCP from the curated registry, the dashboard API communicates with the Operator, which then provisions the necessary resources (Kubernetes Pods) to run the MCP server code (which supports UVX, NPM, and Docker containers). This provides a consistent, reliable mechanism for lifecycle management across diverse MCP runtimes.
The Role of the Proxy: The custom-built Proxy layer sits in front of all deployed MCP server pods. Its main responsibilities are:
Authentication and Authorization 1.
Tool Inspection and Aggregation 1.
Tool Filtering Logic based on configured inclusion or exclusion 1.
Transport Mediation across native protocols
This operator/proxy combination gives the platform total control over the execution environment, enabling high-level features like Virtual MCPs and real-time security scanning that would be difficult to implement with standard cloud components.
My Thoughts
The architectural decision to build a custom Kubernetes Operator and proxy service is a strong indicator of where MCP infrastructure must head to support true enterprise adoption. While general-purpose platforms (e.g., LangChain or ReAct) provide the initial orchestration logic for agents, they often offload the complexity of tool hosting and governance to the user. A managed proxy layer provides the missing enterprise-grade control plane 3.
The Virtual MCP is a compelling paradigm shift. Instead of treating the Model Context Protocol as a simple one-to-one mapping between a service and an endpoint, it re-frames it as a customizable, composite context optimized for a specific agent’s task. This not only solves the issue of context confusion in smaller models but also establishes a critical security boundary: developers can ensure that even if an agent hallucinates a tool call, the underlying destructive capability simply does not exist in its defined context.
A key limitation is that while the platform aims to support Bring-Your-Own-MCP (BYOMCP), the complex custom operator is currently managed exclusively by the platform team. Moving forward, the stated possibility of offering the entire stack, including the operator, for on-premise deployment behind a corporate firewall is a necessary next step for heavily regulated industries. Additionally, the future vision of "intelligent virtual MCPs" that dynamically bring tools online based on agent demand hints at a sophisticated and reactive context management system that will dramatically improve resource efficiency.
Acknowledgements
We thank Sir Valentin Stoican and Sir Alexandru Giurgiu (Founders of mcp-cloud.ai) for presenting their work. Their talk, "Proxying MCPs with mcp-cloud.ai Selective Tool Access, Virtual MCPs and Secure Hosting" 1, at the MCP Developers Summit, provided this deep architectural insight. We are grateful for the continuous contributions from the broader MCP and AI community in advancing agentic infrastructure.
References
Proxying MCPs with mcp-cloud.ai Selective Tool Access, Virtual MCPs and Secure Hosting
↩ 1.
Mitigating Tool Explosion: A Survey on Effective Function Selection for Large Language Models
↩ 1.
Decentralized Governance and Access Control for Agentic AI Infrastructure
↩ 1.
Kubernetes Operators: Automated Management of State-of-the-Art Applications