Remote MCP server

What it is

MCP servers run in two ways. A local server starts as a process on your machine; the client launches it and you write API keys into a configuration file yourself. A remote server runs on the provider's infrastructure; there is nothing to install, keep running or update.

Authorisation happens through OAuth: you sign in to the relevant account, the server stores a scoped token, and that token never reaches the model or gets pasted anywhere by hand. Because it is not tied to a desktop, the same connection works from a phone and a browser.

Why it matters

No runtime to install, no secret sitting in a local JSON file, no version tracking. In exchange you accept two things: a remote server cannot reach your local files, and you are delegating access to your accounts to a provider.

That is why four points should be non-negotiable when you evaluate one: narrow OAuth scopes, per-customer isolation, an audit log and an approval step before write actions.

How Tecrube uses it

Tecrube is the ready-made version of this for advertising: paste the address into your app, sign in with Google, connected in about a minute. No developer token, API key, self-hosting or data pipeline is required.

Each customer's connections are isolated, every write action goes through preview and approval, and everything is logged. The same authorisation is shared across Claude, ChatGPT, Claude Code, Cursor and the other MCP clients.

Example

Even a lost laptop does not expose your ad account: no token lives on the device, and revoking access from your Google account page cuts it in every client at once. On a new computer you paste the same address and sign in again.