# Hosted vs. self-hosted vs. local MCP servers

> Compare hosted, self-hosted, and local MCP servers by setup time, authentication, token refresh, clients, tools, files, scopes, and failures.

Web version: https://claw-link.dev/learn/hosted-vs-self-hosted-mcp-servers

A local MCP server runs on your machine, usually over STDIO. A self-hosted
remote server runs in infrastructure you operate. A hosted connector gives you
a ready-made connection flow, credential lifecycle, and app tools. None is
automatically safer or better; the difference is who operates the integration
and where it runs.

## Decision summary

Choose a local MCP server when one person needs tools on one machine and the AI
host can start the server process. Choose a self-hosted remote MCP server when
an external service cannot hold the credentials, the API is internal, or a team
needs a shared service whose code and network path it controls.

Choose ClawLink when the app is in its catalog and you want OpenClaw, Hermes,
or an MCP-capable agent to use it without registering a provider app or
operating token refresh code.

## Hosted vs. self-hosted vs. local MCP server comparison

The same ten fields appear on each ClawLink operating-model comparison. “Not
measured” means ClawLink has no first-party denominator for that option.

| Field | Local MCP server | Self-hosted remote MCP server | ClawLink hosted connector |
| --- | --- | --- | --- |
| Setup time | Not measured. It includes installing the runtime or package and configuring each local AI host. | Not measured. It includes server configuration or development, deployment, client configuration, and provider credential setup. | The median completed app-connection session was 33 seconds across 3,441 sessions. Initial agent pairing is outside that measurement. See the [connection-time report](https://claw-link.dev/learn/clawlink-connection-time-report). |
| Authentication method | STDIO servers normally read credentials from their environment. Provider authentication depends on the server package. | Protected remote HTTP servers can use the MCP OAuth authorization flow. Provider authentication still depends on the server implementation. | ClawLink's packaged agent surfaces use a `cllk_live_` key; supported remote MCP clients can use OAuth. The connected app uses browser OAuth where supported or a manually supplied credential when the provider has no supported OAuth flow. |
| Token-refresh ownership | The local server package or its operator handles provider-token refresh and revoked access. | The server operator implements provider-token storage, refresh, revocation, and recovery. | Composio handles hosted OAuth tokens and refresh. ClawLink keeps the connected-account reference and reports when a new login is required. |
| Supported agent clients | AI hosts that can start the configured STDIO process on the same machine. Each host needs its own server configuration. | Any compatible MCP host that can reach the server and complete its authentication flow. | OpenClaw, Hermes, the ClawLink CLI, and generic MCP clients through the MCP shim or remote endpoint. |
| Number of tools | Set by the installed server package or local code. | Set by the server operator. | 10 stable MCP control tools expose provider-specific action catalogs. Each integration's current action count is generated from its manifest and shown on its catalog page. |
| File-upload support | Available only when the server tool permits the required local paths and implements the provider's file fields. | Available only when the server implements the provider's file fields and a byte-delivery path. | Available only for actions whose schema accepts a file. Public URLs are rehosted; local-file handling depends on the agent surface. |
| Multi-account support | Implementation-specific. The package must store and select separate provider accounts. | Implementation-specific. The operator must store, select, and isolate account connections. | Yes. A user can keep multiple connections for one integration, choose a connection by ID, and select a default connection. |
| Required scopes | Set by the provider integration in the local server package. | Chosen by the operator, subject to the provider's minimum permissions and the remote MCP authorization configuration. | Integration-specific and shown on the provider consent screen. A user cannot substitute an arbitrary scope set for the hosted configuration. |
| Last tested date | No shared test date. Record it per package version, AI host, and provider tool. | No shared test date. Record this per server deployment and tool. | This comparison and its aggregate production evidence were reviewed on 10 August 2026. That does not mean every catalog integration was runtime-tested that day. |
| Known failure modes | Missing runtimes or packages, invalid client configuration, unavailable environment credentials, denied local paths, and process startup failures. | Redirect or client-registration errors, unavailable server processes, expired or revoked tokens, scope gaps, schema drift, and provider API changes. | Missing connections, expired grants, missing scopes, rate limits, invalid resource IDs, and provider outages. See the [tool-execution report](https://claw-link.dev/learn/clawlink-tool-execution-report). |

The official MCP documentation describes a local server as a process started by
the AI application on the same machine. The authorization specification says
HTTP-based implementations should follow its OAuth flow, while STDIO
implementations should retrieve credentials from the environment. See
[connecting to local MCP servers](https://modelcontextprotocol.io/docs/2026-07-28/develop/connect-local-servers)
and the [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization).

The credential row is a boundary, not a marketing detail. The hosted model is
only appropriate if your organisation accepts a third party in the connection
path. Read ClawLink's [security page](https://claw-link.dev/security) before connecting a sensitive
account.

## What self-hosting actually commits you to

Putting an MCP server on your laptop, a VM, or a private network is only the
first part. For each OAuth provider you generally own the client registration,
redirect URL, token storage, refresh-token rotation, scope changes, and the
failure path when access is revoked. You also own the tool schema your agent
sees and the update cycle when the provider changes its API.

That work is justified for an internal system or a workflow whose tool
behaviour is part of your product. It is often unnecessary for a standard SaaS
app such as Gmail, Notion, Slack, or GitHub, where the objective is simply to
let an agent use an existing account.

## What ClawLink takes over

ClawLink hosts the connection flow and exposes supported app actions to
OpenClaw, Hermes, its CLI, and MCP clients. For an OAuth app, you approve the
provider's consent screen. You do not register your own provider client or put
the provider token in the agent's context.

The hosted path also has limits. ClawLink cannot support an internal API merely
because it has an HTTP interface. It cannot expose a provider capability that
the provider account or consented scopes do not allow. It is also not the right
choice if a policy requires every request and credential to remain inside your
network.

## A concrete decision test

Use this test before building:

1. Is the app a standard SaaS product already in the [ClawLink catalog](https://claw-link.dev/integrations)?
2. Is third-party hosted credential handling permitted for this account?
3. Do you need a custom tool or access to a private network API?
4. Can you own the refresh, revocation, and provider-change work for the life
   of the integration?

If the answers are yes, yes, no, and no, use ClawLink. If the answer to the
second or third question is no, self-hosting is the better fit. If one person
needs a server only on the same workstation, a local MCP server avoids operating
a shared remote deployment.

## What “self-hosted” does not solve

Self-hosting does not reduce the permissions an agent receives. OAuth scopes
still determine what the provider permits, and a tool with permission to send
email can still send email. The same review and write-approval discipline is
needed in either model. For an explanation of that boundary, read
[OAuth for AI agents](https://claw-link.dev/learn/oauth-for-ai-agents).

## Keep reading