MCP Server Hosting: Managed vs Self-Hosted Explained

Modern AI models are brilliant reasoners with no memory of your business. Ask a raw chatbot how last month went and it will invent a plausible answer, because it has no access to your actual numbers. Every serious use of AI for real work runs into the same wall: the model needs to see and act on your live data, and it needs to do so safely.

The Model Context Protocol, or MCP, is the open standard that solves this. It defines how an AI client connects to an external server, discovers the tools that server exposes, and calls them with structured inputs. Think of it as USB for AI: one protocol, and any compliant model can plug into any compliant server.

MCP server hosting is simply the question of who runs that server. Self-host and you write, deploy, and operate it yourself; use a managed platform and you configure sources while the host handles auth, transport, uptime, and security, producing a production-ready remote endpoint. BusinessMCP is the managed kind, with a twist: it unifies many sources into one server rather than hosting one server per tool.

The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools.

Self-hosting an MCP server means writing it with an SDK, running it as a process (locally over stdio, or on your own infrastructure over HTTP), and owning everything around it: authentication, token storage, TLS, scaling, logging, and keeping up with a protocol that is still evolving quickly. None of that is exotic engineering — but all of it is recurring work that has nothing to do with your business.

A hosted MCP server flips the deal: the platform runs the server, and you decide what it exposes. You are not choosing between capability and convenience — a good host gives you more control surface (scoped keys, tool allowlists, audit logs) than a weekend self-hosted build ever grows. You are choosing who carries the operational and security burden.

Early MCP was local-first: servers ran as processes on your own machine, wired into a desktop client over stdio. That works for developer tools, but a business data platform cannot live on one laptop. Remote MCP servers changed the shape of the ecosystem: the server lives at an https URL, speaks the streamable HTTP transport, and any MCP-capable client — Claude, other agents, your own automations — connects with a URL plus credentials. We walk through the trade-off in depth in the remote vs local MCP server guide.

Authentication for remote servers has standardized around two patterns: OAuth, where the client discovers how to authenticate via a well-known protected-resource metadata document, and Bearer keys, where a workspace-scoped secret authorizes each request. BusinessMCP supports both — the endpoint advertises its OAuth metadata and accepts mcph_ Bearer keys — so anything from Claude Desktop to a cron job can connect without custom plumbing.

A hosted MCP server sits between your data and any AI agent. On one side it connects to your sources: your website analytics, your CRM, your ad platforms, your Stripe revenue, and whatever tools you authorize. On the other side it presents a clean, authenticated endpoint that agents talk to over a standard transport.

When an agent connects, it asks the server "what can you do?" and receives a list of tools with typed schemas. To answer a question, the agent picks a tool, fills in the arguments, and calls it; the server executes against your real data and returns a structured result. The agent then turns that result into a plain-language answer or a further action.

Everything runs behind a Bearer key scoped to your workspace, and every call is logged. That means the agent never touches raw credentials for your underlying tools — the host holds those securely and mediates every request. You get the flexibility of AI with the control of a permissioned API.

Auth and identity: issuing and revoking scoped keys, OAuth discovery, and tenant isolation enforced at the database so one workspace can never read another. Credentials: the OAuth tokens and API keys for your underlying tools live in an encrypted server-side vault — agents get tools, never the raw secrets behind them.

Scaling and uptime: the endpoint is always on and handles concurrent agents without you provisioning anything. Observability: every tool call is logged — which tool, what arguments, what result — so agent behavior is auditable rather than a black box. And governance: per-connection tool allowlists, access policies that redact sensitive classes of data per key, and approval gates on consequential actions like sending email.

That list is also a useful test of any host you evaluate: each item is table stakes for exposing real business data to autonomous agents, and each is weeks of work to build properly yourself.

Most integrations give an agent one tool at a time: a Stripe connector here, an analytics connector there. That is useful, but it leaves the agent stitching context together across disconnected surfaces — and it leaves you managing a sprawl of separate connections.

BusinessMCP takes the opposite approach: it unifies your tools, databases, ad platforms and revenue into one hosted MCP server plus a business-intelligence dashboard. The agent sees your whole business as a single, coherent surface. Ask it about the relationship between ad spend and revenue, and it can pull both because both live behind the same endpoint with a shared identity graph tying visitors to customers.

This unification is also what makes the data genuinely AI-ready. First-party, cookieless analytics feed a durable rollup; the CRM stitches visitor to email to Stripe customer; revenue is attributed back to channels. By the time an agent queries it, the data is already reconciled — the agent reasons over answers, not raw noise.

Managed MCP hosting is typically priced like SaaS: a free tier to test with, then flat monthly tiers keyed to usage — seats, data volume, or agent activity. BusinessMCP, for example, runs from a free tier through paid tiers priced on monthly tracked users and AI runs. When you compare, look at what is actually metered: tool calls, events, connected sources, and whether bringing your own LLM key changes the bill.

Self-hosting looks cheap on infrastructure — a small server costs almost nothing — but the real line item is engineering time: building auth and logging, storing credentials safely, and tracking a fast-moving protocol. For most teams the honest comparison is a modest subscription against recurring engineer-days, which is why managed usually wins unless you have a specific reason it cannot.

Transport and auth first: it should speak streamable HTTP, support OAuth discovery and per-key Bearer auth, and let you issue one key per agent with instant revocation. Then security posture: are source credentials held server-side in a vault, is tenant isolation enforced at the database, is every tool call logged?

Then governance: can you scope what each key can reach (tool allowlists, data-class policies), and are consequential actions gated behind human approval? Finally, breadth and lock-in: model-agnostic by design, enough connectors for your actual stack, and a clear answer to "can I export my data if I leave?" A host that is vague on any of these is asking you to trust instead of verify.

1. 1Speaks streamable HTTP and supports OAuth discovery plus per-key Bearer auth
2. 2One key per agent, with instant revocation
3. 3Source credentials held server-side in a vault — never exposed to agents
4. 4Tenant isolation enforced at the database, not just in application code
5. 5Every tool call logged — tool, arguments, result
6. 6Scoping: tool allowlists and data-class policies per key
7. 7Human approval gates on consequential actions (sending, spending)
8. 8Model-agnostic by design, with a clear data-export answer

Honest answer: sometimes you should. Self-host when the server wraps proprietary internal systems that cannot leave your network, when compliance or data-residency rules require infrastructure you control end to end, or when the MCP server itself is your product and you have platform engineers to own it. A local stdio server is also perfectly fine for a personal developer tool that never needs to be reachable by anyone else.

Use managed hosting when the job is exposing unified business data — analytics, CRM, revenue, ads — to agents safely, when the team is small, or when the endpoint must be reliably reachable by external agents. Many teams land on both: a managed platform for the business layer, plus a self-hosted server for the one internal system that can never leave the building.

MCP hosting fits two audiences. Self-serve teams want business intelligence in one place and an AI that can actually act on it — a founder and a couple of agents running growth without a data team. For them, the cloud app plus a hosted endpoint is a force multiplier.

Enterprises want to expose their business to AI agents safely, without handing over credentials or building bespoke servers per tool. For them, MCP hosting is an integration layer: a controlled, auditable endpoint that any approved agent can use. Both audiences get the same core promise — your business, unified and AI-ready, behind one secure MCP server.