Lanes Link vs per-provider remote MCP servers

More services ship their own remote MCP server every month. You point your agent at Notion's, authorize it, and it works, with nothing to run and nothing to maintain. Repeat per service and per client, and you have a working setup.

This is less a rivalry than a question of layering, and worth saying plainly: Lanes Link reaches Notion and Linear through their own remote MCP servers. The comparison is not "which server," it is whether you want a boundary of your own in front of them.

At a glance

Dimension	Lanes Link	The provider's own MCP server
Who runs it	You, on your machine or your own cloud	The provider
Setup cost	An endpoint to start and keep current	Nothing to run
Registration per client	One endpoint, every provider behind it	Each server, in each client
Where credentials sit	Your machine or your bucket	The provider's cloud, on its own terms
Permissions	Deny by default, per capability, enforced by the runtime	The scopes that provider chooses to expose
Audit	One append-only, hash-chained record per call, across every provider	Per provider, where offered
Work and personal	A required `profile` argument on every call	Usually a separate account or client per world
Memory, skills, secrets	Served by the same endpoint, no credential needed	Out of scope
Coverage	The providers Lanes Link implements today	Whatever that provider ships, immediately
Docs	lanes.sh/docs/link	each provider's own docs

Where Lanes Link fits

Lanes Link earns its keep when the count goes up: more providers, more clients, or more than one world to keep separate. Five services across three harnesses is fifteen registrations and fifteen consent screens done directly, and one endpoint plus five connections through Lanes Link. Revoking an account is one action rather than a hunt.

It also owns the things no single provider can offer, because they are not any provider's job. One audit log that spans Gmail and Notion and Linear together. One policy language where gmail.search = allow and gmail.send = deny are enforced before dispatch. Profiles, so work and personal are separate worlds under one token. And the owner layer, memory, skills, and a vault, which serve without any account connected at all.

Where per-provider servers fit

If you use one service and one client, connecting directly is simply better. There is no endpoint to run, no process to keep alive, and no version of the integration that can lag behind the provider's own API, because it is the provider's own API. First-party servers also get new capabilities the day they ship, with no work from you and no waiting on anyone else's release.

Be honest about scale before adding a layer. A self-hosted endpoint is a thing you own: it has to be running for your agent to reach anything, and on your own cloud it is a deployment with a lifecycle. That is a fair trade for a fleet of clients and a real permission boundary, and pure overhead for one person using one tool with one Notion workspace.

How Lanes Link does it

It aggregates rather than reimplements. Notion and Linear are reached through their own remote MCP servers, and they register themselves. Lanes Link adds the boundary, not a second-guess of the provider's API.
One registration covers every client. lanes link mcp add finds Claude Code and Codex, registers the endpoint with each, and installs a skill and scout agent so the agent knows what it can reach.
Policy is runtime, not prompt. Every capability is denied until you allow it, and policy only tightens as a request travels inward. A refused call is recorded like any other.
The audit spans providers. One append-only event per invocation, with per-provider redaction that keeps the identifiers and withholds your content. lanes link audit verify walks the hash chains.
Local first, cloud when you need it. Locally it needs Bun and no account anywhere. lanes link deploy stands up a Cloud Run revision when you need to reach the endpoint from the claude.ai web client, ChatGPT, or a phone.
Providers are additive. A new one lands without touching the core, and docs/creating-a-provider.md is written to be enough on its own.

Choose Lanes Link if

You use several MCP clients and do not want to authorize each service in each one.
You want one audit log covering every provider, including the calls that were refused.
You want per-capability policy that the runtime enforces, not scopes the provider happens to expose.
You keep work and personal apart and want that enforced rather than remembered.
You want memory, skills, and a secret vault behind the same boundary as your accounts.

Choose per-provider servers if

You use one or two services from one client, and adding an endpoint is more than the problem needs.
You want a provider's newest capabilities the moment they ship.
You would rather run nothing at all.

These are not exclusive. Connecting a provider directly today and putting Lanes Link in front later costs you nothing, because the provider's server is what Lanes Link would be calling anyway.