LanesLanes
Use cases/Lanes Link/Ship your agent, not its integration layer

Ship your agent, not its integration layer

Let one MCP endpoint hold authentication, credentials, permissions and provider integrations, so the part you build is your product rather than the plumbing under it.

The demo takes an afternoon. Then a user asks for their own Gmail, and the next three months go on OAuth clients, token refresh, encrypted storage, a permission model, per-customer isolation, and an audit trail somebody's procurement team asked for. None of it is your product. All of it is now yours to keep running.

Lanes Link is that layer, already built and open source. You point your agent at one MCP endpoint and it arrives with the accounts, the policy and the log attached.

How Lanes Link does it

  • Authentication is the endpoint's problem. Link implements OAuth 2.0 for its own MCP endpoint, including RFC 8414 authorization server metadata, RFC 9728 protected-resource metadata, dynamic client registration and PKCE. Any compliant MCP client can register itself.
  • Credentials never reach your code. Tokens live behind the endpoint. Your agent sends a tool call and receives a result, so there is no secret in your process to leak, rotate or store.
  • A permission model you did not write. Access Profiles decide which accounts a caller reaches, what it may do with each, and who may use it. Deny by default, enforced before dispatch rather than asked for in a prompt.
  • Over a hundred providers, already connected. Mail, calendars, files, issue trackers, CRMs, billing and the rest, one command each. The list is in Every provider.
  • Anything else, in a file rather than a codebase. Add your own covers any MCP server, any REST API with an OpenAPI description, any IMAP mailbox, any CalDAV or CardDAV server, and any folder. Same permissions, same audit log.
  • The audit trail is already there. Every call the endpoint served, allowed or refused, in an append-only log. That is usually the question that stalls a security review.

The workflow

Treat the endpoint as your integration boundary from the first commit. Your agent speaks MCP to one address, and everything a customer connects appears through it.

Isolation per customer is a profile rather than a deployment. A profile holds its own memory, tasks, skills and entities, grants its own slice of the connected accounts, and names who may use it, so one endpoint serves many tenants without your code learning what a tenant is.

When a customer asks for a provider you have never heard of, the answer is a connect command or a short YAML file, not a sprint. Your roadmap stops being a list of other companies' APIs.

Set it up

A local endpoint takes three commands and no account anywhere. It needs Bun 1.3.11+ and nothing else.

console
$ bun install -g @lanes-sh/link
$ lanes link profile add demo --default
$ lanes link start
ok    serving http://127.0.0.1:7337/mcp
      profiles: demo

Then:

  1. Point your agent at it. Register http://127.0.0.1:7337/mcp as an MCP server, or let lanes link mcp add do it for the CLIs you have installed.
  2. Connect one account. lanes link connect gmail, and your agent can already read mail it never got a token for.
  3. Narrow the policy. Allow the two capabilities your product needs and leave the rest denied.

When you are ready for it to be reachable from somewhere other than localhost, run it in your own cloud.

Building this yourself is not impossible, it is just permanent. Every provider is an integration to maintain, every token is a rotation to schedule, and the permission model is the piece you will be asked to prove in every security review for the life of the product.

Further reading

Browse the source at lanes-sh/link, Apache-2.0, or read the announcement.