Cline's setup lives entirely in its MCP panel, and the more interesting fact is what happens after: the model Cline is running underneath stops mattering for how the board behaves.

Connect it

Open the MCP Servers icon in the Cline toolbar and choose the Remote Servers tab. Name it develosaur, paste the address, pick Streamable HTTP, and add the server:

https://mcp.develosaur.com/v1/user/mcp

The same entry works if you would rather write it directly into cline_mcp_settings.json. Complete the browser sign-in Cline opens, then ask it something: "Read my develosaur board digest."

Why the model does not matter here

Cline can run frontier models or considerably smaller and local ones, and the same board works the same way with either. The rules, the ranked list, the lease that keeps two agents from claiming the same task, the pipeline gate that decides what even counts as work, all of it lives on the server. A model does not have to remember or reconstruct any of it from a system prompt; it just calls the same verbs, and the server enforces what those verbs do. A weaker model can still follow a correct work loop it did not have to be smart enough to invent on its own.

If it stays disconnected

An older Cline build lacking sign-in support for remote servers is the most common cause; updating Cline resolves it. A sign-in page that loops back means the email link opened in a different browser than the one that started the request, so finish it in the same one; a proxy or VPN blocking the callback usually clears on a retry off that network.

Full setup, troubleshooting and FAQ live on the Cline integration page. The lease system this depends on is covered in several agents, one plan; more of these are on the blog.