MCP

Lanes speaks the Model Context Protocol so agents like Claude Code and Codex can drive it from a chat prompt. There are three separate Lanes MCP servers, and they do different jobs:

• Lanes MCP is hosted by us. Today it powers Lanes Forms: an agent can provision and fill form backends over MCP, with nothing to install.
• Lanes Desktop MCP is built into the Lanes desktop app. It runs on your machine and gives an agent read and write access to your issue board, sessions, and connected GitHub and Linear accounts.
• Lanes Link MCP is the odd one out, and deliberately so. It does not expose Lanes at all. It is one endpoint you run yourself that holds your own accounts, memory, skills, and secrets, and decides what each agent may do with them.

They are independent. Connect one, two, or all three: they register under different names (lanes, lanes-desktop, and lanes-link) so they never collide.

At a glance

Lanes MCP (Lanes Forms)

Lanes MCP is hosted, so there is nothing to install. Add it to your agent and ask it to provision a form backend or submit to one. Anonymous calls work with no signup; a workspace key (lfk_...) unlocks the management tools and provisions forms straight into your workspace.

See Agents and MCP for the tools, the setup command, and the Claude Code skill.

It currently exposes Lanes Forms, which is why we frame it as "for now". It is named simply lanes so it can grow to cover more of Lanes over time.

Lanes Desktop MCP

Enable it in the desktop app under Settings, then Local MCP. Once connected, an agent can read and triage your board, start and resume sessions in worktrees, and reach your connected GitHub and Linear accounts, all without leaving chat. Everything stays on your machine, and no key is involved because the server only listens on localhost.

Full details, the complete tool list, and example prompts are in Lanes Desktop MCP.

Lanes Link MCP

The other two servers give an agent access to Lanes. Lanes Link MCP gives it access to you: the accounts you have connected, what you know, the procedures you reuse, and the credentials you would rather not paste into a prompt. Lanes does not host it and cannot see it. You run it, on your own machine or in your own cloud project.

It is worth connecting even with nothing linked. Memory, skills, and the vault are the owner layer and serve without a credential of any kind, so a brand new endpoint is already useful. Connections come later, one provider at a time: Gmail, Drive, Sheets, Docs, Calendar, Tasks, and Contacts on Google; Mail, Calendar, Contacts, and Drive on iCloud; GitHub, Notion and Linear through their own remote MCP servers.

Two things shape every call. Every capability is denied until you allow it, and that is enforced by the runtime rather than asked of the model, so gmail.search = allow with gmail.send = deny holds whatever the agent was told. And every call carries a required profile argument, so work and personal never depend on remembering which context you are in.

A local endpoint needs Bun 1.3.11+ and no account anywhere:

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

Then lanes link mcp add registers it with every harness you have installed, and lanes link connect gmail opens a browser for the first account. There is no OAuth client to register: Google connections authorise against the one Lanes operates, and --own-client registers your own if you would rather. The Lanes Link page covers what each scope is for. Since v0.47.0 the desktop app can do all of that for you from a page in its settings: see Lanes Link in the desktop app. Full documentation is at Lanes Link docs, and the source is lanes-sh/link, under Apache-2.0. The announcement post covers the permission model, profiles, and the audit log in depth.