Understanding MCP Hosting: Deploying and Running MCP Servers in the Enterprise

Obot AI | Understanding MCP Hosting: Deploying and Running MCP Servers in the Enterprise

MCP hosting involves running and maintaining a Model Context Protocol (MCP) server, either locally or remotely. The MCP servers being hosted might be single-tenant, user-specific servers, multi-tenant or shared MCPs, or vendor-provided third-party MCPs.

How is MCP server hosting different from hosting other types of software? Most organizations run software in the cloud or on platforms like Kubernetes, so should they run MCPs the same way? It’s important to realize that MCP servers are tricky to host, because they don’t come in just one variety, and they often require a centralized approach to monitoring and security.

In this article, I’ll break down the different types of MCPs enterprises need to host, and why a a unified approach to managing could be worth the investment.

Also check out our recent articles about MCP Security, Gateways, Proxies and strategy.

Why MCP Hosting Matters

MCP servers can unlock the power of AI inside the enterprise by exposing APIs, data sources, and applications to large language models (LLMs). But without a hosting strategy, MCPs often run in an ad-hoc, decentralized way—on individual developer laptops, internal servers, or unmanaged cloud instances.

The result? Shadow infrastructure, security blind spots, and no clear way to monitor adoption or enforce policies.

By building a platform for MCP hosting, enterprises can:

  • Ensure MCP servers are deployed in a consistent, secure environment
  • Provide reliable access to developers and employees across the company
  • Apply centralized governance and auditing
  • Enable scalable adoption of AI tools and workflows

MCP Server vs. MCP Hosting

An MCP server refers to the individual component in the MCP architecture that connects to a specific tool or data source—such as a calendar, codebase, or document store. It exposes functionality that an AI model can use via the MCP protocol, typically through a lightweight local app like an ExpressJS or FastAPI server. These servers are simple to build and often run locally on a developer’s machine, especially during prototyping or personal use.

MCP hosting is a strategy for deploying and managing these servers in a scalable, secure, and reliable way across an organization. Without formal hosting, servers tend to run in ad-hoc environments—making them hard to govern, monitor, or secure. Centralized hosting enables teams to deploy MCP servers in a consistent environment (e.g., a managed cloud), control access, and integrate them into enterprise workflows.

The distinction matters because while the server itself can be a tiny local process, hosting determines how it scales, who can use it, and whether it meets enterprise standards for observability, access control, and reliability.

The Three Types of MCP Servers Organizations Need to Manage

Not all MCP servers are the same. Enterprises typically need to support three main types of MCPs:

1. Single-Tenant MCPs (User-Specific Servers)

Many MCPs are designed to run locally, often on a developer’s laptop. For example, an MCP might connect an agent to a user’s local development environment, file system, or private dataset.

In an enterprise, this doesn’t scale. We addressed this in Obot MCP Gateway by hosting single-tenant MCPs remotely in Kubernetes. Each user’s MCP runs in its own secure container, isolated from others, but centrally managed by IT. This allows developers to keep using MCPs as they always have—without relying on fragile, laptop-based setups.

2. Multi-Tenant / Shared MCPs (Central Services)

Some MCPs are best hosted once and shared across multiple users. Think of an MCP that connects to Jira, Datadog, or Slack. Instead of every user spinning up their own instance, IT can run a single, multi-tenant MCP on Kubernetes through Obot, making it available to all authorized employees. OAuth can be used to authorize users and connect them with their identity on the shared platform.

This reduces infrastructure overhead, simplifies updates, and ensures consistent access to enterprise-wide services.

3. External Third-Party MCPs (Vendor-Provided)

Finally, not every MCP will be hosted inside the enterprise. Vendors and SaaS providers are beginning to offer MCP endpoints directly (e.g., from Zapier or AWS). Enterprises still need to control how these MCPs are accessed.

With Obot, external MCPs can be onboarded into the enterprise MCP catalog and routed through Obot’s proxy. This means IT retains full control and auditing capabilities, even when the MCP itself is hosted outside the organization.

Local Hosting

In local hosting, the MCP server and client run on the same machine using the stdio transport. This setup is ideal for development or when users want to run tools locally without deploying them to a remote environment.

Let’s walk through how to set this up using a simple Demo  MCP server written in Python.

We need to install the following Python libraries:

pip install "mcp" "httpx" "beautifulsoup4" "mcp[cli]"

First, create your server.py:

import asyncio  import platform  # Prefer FastMCP (high-level API). Fallback to low-level Server decorators if FastMCP isn't available.  try:      from mcp.server.fastmcp import FastMCP      mcp = FastMCP("MCP-Demo-Server")      @mcp.tool()      def echo(text: str) -> str:          return f"Echo: {text}"      @mcp.tool()      def add(a: float, b: float) -> float:          return a + b      @mcp.tool()      def system_info() -> str:          return f"OS: {platform.system()} | Python: {platform.python_version()}"      if __name__ == "__main__":          # STDIO transport (works with ClientSession + stdio_client)          mcp.run(transport="stdio")

You can run the server manually with:

python server.py

But in practice, clients like Claude Desktop will launch the server automatically. When you run mcp install server.py, it registers the MCP server in Claude’s configuration. Claude then starts the server as a subprocess using uvx for Python or npx for JavaScript.

If needed, you can manually add an entry to claude_desktop_config.json like this:

"MCP-Demo-Server": {    "command": "uv",    "args": [      "--directory",      "<Folder-containing-server.py>",      "run",      "server.py"    ]  }

Under the hood, local hosting uses standard input/output streams (stdio) for communication. No network ports or HTTP are involved. The client starts the server process and communicates directly via stdin/stdout, keeping things simple and fast.

To make the MCP server reusable, you can publish it as a Python package on PyPI or a JavaScript package on npm. Once packaged, other users can install it and connect via configuration entries like:

"mcp_demo_server": {    "command": "uvx",    "args": ["mcp-demo-server"]  }  or  "mcp_demo_server": {    "command": "npx",    "args": ["mcp-demo-server"]  }

This approach makes local MCP tools easy to share and version, while still running fully on the user’s machine.

Remote Hosting

Remote hosting allows MCP clients to connect to a server running on the internet, which is essential for making tools accessible across machines and teams. This setup uses Server-Sent Events (SSE) as the transport layer.

To support this, you’ll update the MCP server to use SSEServerTransport. Here’s an example in TypeScript, It simply converts given code in title case t:

import axios from "axios";  import { z } from "zod";  const server = new McpServer({ name: "mcp-demo-server", version: "1.0.0" });  const toTitleCase = (s: string) =>    s.toLowerCase().replace(/\b\w/g, (c) => c.toUpperCase());  server.tool(    "titlecase-text",    { text: z.string().min(1) },    async ({ text }) => ({      content: [{ type: "text", text: toTitleCase(text) }],    })  );

You’ll also need to expose two endpoints in an Express server:

  • /sse – for establishing the long-lived SSE connection
  • /messages – for receiving messages from the client
import express from "express";  import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse";  const app = express();  app.use(express.json());  const transports = new Map(); // sessionId -> transport  // 1) SSE: client opens a long-lived connection here  app.get("/sse", async (req, res) => {    const transport = new SSEServerTransport("/messages", res);    transports.set(transport.sessionId, transport);    res.on("close", () => transports.delete(transport.sessionId));    await server.connect(transport); // server = your McpServer instance  });  // 2) Messages: client posts tool-call payloads here (with ?sessionId=...)  app.post("/messages", async (req, res) => {    const sessionId = String(req.query.sessionId || "");    const transport = transports.get(sessionId);    if (!transport) return res.status(400).send("No transport found");    await transport.handlePostMessage(req, res);  });  app.listen(3000, () => console.log("MCP SSE server listening on :3000"));

To deploy this server, push it to a GitHub repo and connect it to a platform like Render. Set the build command to:

npm install && npm run build

And the start command to:

npm start

Once deployed, you’ll receive a public URL (e.g., https://demo-mcp-server.onrender.com). Claude Desktop can now connect to this server using the /sse endpoint. Add an entry to your Claude configuration:

"demo-mcp-server": {    "url": "https://demo-mcp-server.onrender.com/sse"  }

Remote hosting is ideal for shared or production-grade MCP tools. The SSE transport allows clients to communicate with the server over HTTP without relying on local execution. However, keep in mind that SSE comes with limitations in scalability and reliability, which you’ll need to address for large-scale deployments.

Managing all three types of MCPs—single-tenant, shared, and external—requires a flexible hosting model. That’s where Obot MCP Gateway comes in.

  • For IT teams, Obot provides an administrative control plane to onboard, configure, and secure MCPs—whether hosted internally or added from third parties.
  • For users, Obot offers a searchable catalog and simple connection flows, making MCPs easy to discover and integrate with their AI clients.
  • For enterprises, Obot acts as a secure proxy for all MCP communication, ensuring compliance, visibility, and scalability.

By combining hosting, proxying, and governance in one platform, Obot transforms MCP hosting from a fragmented problem into a streamlined enterprise capability.

As enterprises expand their AI initiatives, MCP hosting will become a foundational layer of IT infrastructure. The ability to host, manage, and govern MCPs at scale will determine how effectively organizations can unlock the full potential of AI agents and applications.

With Obot MCP Gateway, enterprises can stay ahead of the curve—building a secure, scalable platform for MCP hosting that supports innovation while protecting the business.

Ready to explore MCP hosting for your organization?
Learn more about Obot MCP Gateway and see how it can help you securely manage and scale MCP adoption across the enterprise.

Related Articles