Hosted vs Self-Hosted MCP Aggregation

Start With the Boundary

An MCP aggregator is a runtime boundary between clients and sources. The client sends protocol requests such as tools/list and tools/call; the boundary decides which upstream systems are visible, how names are disambiguated, which credentials are used, and what gets logged. Hosting changes who operates that boundary, but it does not remove the boundary work.

The hosted version usually looks like one remote MCP URL that every approved client uses. For example, a Claude Code setup can stay small:

claude mcp add --transport http workspace https://mcp.example.com/agent/mcp \
 --header "Authorization: Bearer $AGENT_MCP_KEY"

The self-hosted version may expose the same protocol surface, but your team owns deployment, patches, scaling, observability, backups, secret storage, OAuth callback handling and on-call response. That can be right for a regulated internal platform, but it is a real operations commitment.

Compare the Responsibilities

If most rows point to the same side, the decision is probably straightforward. If they split, choose the side that matches the riskiest workload first. A prototype that reads public issue metadata does not need the same answer as a production agent that can touch billing or deployment systems.

Protocol Shape Matters

MCP's HTTP transport makes hosted aggregation more practical than earlier session-heavy designs. The transport specification describes Streamable HTTP as messages posted to a single endpoint, with protocol semantics staying the same across bindings. The 2026-07-28 MCP release moved the core toward stateless request and response behavior, with metadata available for routing and authorization.

Self-hosting also gets easier. A stateless core means an internal aggregator can be treated more like other HTTP services: run multiple instances, send requests through existing ingress, and avoid hidden per-connection server state. But if the tool list changes, a token expires, or an upstream server returns a tool execution error, your implementation still has to produce behavior that clients and models can recover from.

Use raw JSON-RPC checks during evaluation. A discovery request should be deterministic for the same credential:

{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "tools/list",
 "params": {}
}

A harmless read call should identify the intended source and arguments clearly:

{
 "jsonrpc": "2.0",
 "id": 2,
 "method": "tools/call",
 "params": {
   "name": "linear.search_issues",
   "arguments": { "query": "invoice import bug" }
 }
}

Security Is Not Just Location

Self-hosting gives control over the machines, network path and release process. It does not automatically give least privilege. Hosted aggregation gives operational leverage, but it does not automatically make every source safe to expose. In both models, the meaningful checks are the same: who may list a source, who may call a tool, which scopes were granted, what happens when a write tool appears, and whether sensitive arguments are shown before execution.

The MCP tool specification says servers must validate tool inputs, implement access controls, rate limit invocations and sanitize outputs. It also notes that tool name uniqueness is scoped to a single server, so an aggregator has to handle collisions instead of forwarding two ambiguous search tools. The authorization specification for HTTP transports uses bearer access, protected resource metadata, scopes and runtime permission errors.

A hosted vendor should be able to explain its key model, upstream token model, audit records and failure reporting. A self-hosted build should have those answers in code and runbooks. A prompt that says "do not write" is documentation, not enforcement. The runtime boundary must refuse calls the credential is not allowed to make.

When Hosted Wins

Hosted aggregation is usually the better first move when your source set is broad and mostly SaaS. The work you are buying is connector setup, upstream sign-in, remote endpoint exposure, short client configuration, namespacing, permissions, error handling and logs shaped around agent traffic.

Hosted also fits teams that are still comparing clients. If Claude Code, Cursor, ChatGPT or another MCP client may become the daily interface, one stable endpoint keeps the experiment clean. You can change the client without reconnecting every upstream system, and judge the client on model behavior rather than on who has the most hand-maintained local config. That portability connects directly to switching agents without rebuilding integrations and agent-agnostic architecture.

The tradeoff is dependency. You need to accept the provider's hosting region, feature set, incident handling, connector roadmap and data-processing posture. If your organization requires private deployment, custom identity federation today, or direct control of every credential store, hosted may be the wrong boundary.

When Self-Hosting Wins

Self-hosting is strongest when the aggregator is part of an internal platform rather than a convenience layer. Examples include private-network sources, strict change-control windows, custom agent identity work, unusual approval flows, or a requirement that all logs stay inside existing observability and retention systems. The MCP roadmap calls out agent identity and enterprise-ready security as active areas, a reminder that some organizations need deeper identity integration than a generic API key can provide.

A self-hosted design should start small and explicit. Put the aggregator behind normal ingress, terminate TLS in the standard place, store upstream secrets in the organization's vault, and expose one remote MCP endpoint to clients. Then make the operational contract concrete:

1. How are upstream OAuth grants created, refreshed and revoked?
2. Which team approves new tool sources?
3. How are read tools distinguished from write tools?
4. What happens when an upstream MCP server is unreachable?
5. Where are caller, source, tool, result status and latency logged?
6. Who receives alerts when tools/list or tools/call starts failing?

If those answers are fuzzy, make the first milestone operational rather than another connector.

How SPYN3 fits this choice

SPYN3 is the hosted option. The API runs in Amsterdam on Fly.io, the database is Supabase in eu-west-1 (Ireland), and encrypted backups go to Frankfurt nightly. You do not run the proxy, the upstream OAuth flows or the tool catalog. The trade-off is the one this article describes: tool traffic passes through SPYN3, so its availability and its logging become part of your path. Upstream credentials are encrypted at rest, and connected content is proxied rather than stored.

A Practical Decision Rule

Pick hosted to connect existing systems once, keep client configs small, and give developers a governed endpoint quickly. Pick self-hosted if the main job is infrastructure ownership, private-network access, bespoke identity, custom controls or internal audit workflows. Do not split the difference by letting every agent configure its own upstream servers; that recreates the sprawl aggregation was supposed to remove.

A useful evaluation plan is two weeks long. In week one, connect three read-heavy sources and one client through the candidate boundary, then test tools/list, a read call, a denied write and an upstream failure. In week two, add a second client and rotate the agent credential without touching upstream source credentials. If hosted passes and meets your risk requirements, use the time you saved elsewhere. If it fails on a hard requirement, self-host with the requirement written down. For adjacent control questions, compare scoped API keys for AI agents and audit logging for agent tool calls.