Self-hosted vs hosted MCP server: which should you build?

Once you decide you want to make something queryable via MCP — your docs, your API, your product data — the next question is: do you build and host the MCP server yourself, or do you use a hosted service?

Both are valid. The right answer depends on what you're trying to expose, how much infra you want to run, and how much control you actually need. Here's the breakdown.

What you're actually building

An MCP server is an HTTP server (or a stdio subprocess) that implements the JSON-RPC 2.0 protocol and exposes tools. A minimal one looks like this:

// tools/list — what the client calls first
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// tools/call — what the client calls to use a tool
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "my_tool",
    "arguments": { "query": "something" }
  }
}

The server responds with tool definitions (name, description, inputSchema) and tool results (content array with text). Anthropic has TypeScript and Python SDKs that handle the boilerplate — you mostly just write the tool functions.

So building the protocol layer is not the hard part. The hard part is everything else: crawling and parsing content, building a vector index, handling embeddings, managing rate limits, running reliably at 3am, and keeping it updated as your site changes.

The case for self-hosting

Self-hosting makes sense when your use case requires it. The main reasons:

Private data. If you're exposing internal docs, proprietary APIs, or customer data, you probably can't send that to a third-party indexing service. Self-hosting keeps the data on your infrastructure.

Custom tool logic. Not everything is a docs query. If you want to expose tools that write to a database, call a custom API, or do something bespoke to your product, you need to write the tool yourself. No hosted service can anticipate every use case.

Deep integration. If your MCP server needs to authenticate users, check permissions, or tie into your existing auth system, building it yourself gives you that control.

Specific latency or compliance requirements. Running the server in your own region or VPC lets you meet requirements a hosted service may not.

The trade-off: you own the infra. Crawling and re-crawling content, managing embeddings, handling edge cases in web content parsing, keeping the server up — that's yours to build and maintain.

The case for hosted

For public-facing content — docs sites, marketing pages, product documentation — self-hosting is mostly unnecessary complexity. The content is already public. The indexing logic is the same for everyone. The only thing that varies is the domain.

A hosted MCP service like AgentReady takes care of:

— Crawling the site (including JS-rendered content via Jina fallback)

— Chunking and embedding the content

— Running the vector index and serving queries

— Keeping the index fresh with refresh_site

— Hosting the MCP endpoint so any client can connect

You submit a URL, wait ~60 seconds, and the site is queryable. No infrastructure. No embeddings pipeline. No vector database to manage.

The trade-off: you get the same tool logic as everyone else (ask, submit, refresh, list). That's a feature if your use case is "query these docs" — it's a limitation if you need something custom.

A middle path: use hosted for public, self-host for private

Many teams end up with both. Public docs and marketing content go through a hosted service — why build infrastructure for that? Internal docs and proprietary APIs run on a self-hosted server.

In Claude Desktop, this looks like having two MCP servers configured: one pointing to your hosted endpoint (a URL), one pointing to your internal server (an npx command that runs locally or connects to your VPN). Claude sees both sets of tools and picks the right one based on context.

// claude_desktop_config.json
{
  "mcpServers": {
    "agentready": {
      "command": "npx",
      "args": ["-y", "@agentreadyweb/mcp"]
    },
    "internal-docs": {
      "command": "npx",
      "args": ["-y", "@yourcompany/internal-mcp-server"]
    }
  }
}

The AI client doesn't care where the tools come from. It calls whatever is available.

When to start with self-hosting

Start self-hosting from day one if:

— The content is private and can't leave your infrastructure

— You need tools that do more than query content (write operations, custom auth, etc.)

— You have specific SLAs or compliance requirements

— You want to learn the MCP protocol deeply by implementing it

Otherwise: use a hosted service to get to useful fast, then self-host the parts that actually need to be custom. Building infrastructure to serve public content is usually premature optimization.

Rough effort comparison

Hosted (AgentReady or similar): ~5 minutes to set up. Submit URL, copy npm config, done. Ongoing maintenance: zero.

Self-hosted, basic: A day or two to build a working MCP server that reads from a static source. A week if you need crawling and embeddings.

Self-hosted, production: Several weeks for a robust implementation with re-crawling, rate limiting, auth, monitoring, and reliable uptime. Ongoing maintenance is yours.

That's not an argument against self-hosting — it's just calibrating expectations. The protocol is simple; the pipeline around it is what takes time.