Connecting an AI assistant over MCP

MCP (Model Context Protocol) is how an assistant reaches tools it does not ship with. Point yours at Browser.lol and it can open pages, read them, click, type, fill forms, upload files, run JavaScript and take screenshots in an isolated cloud browser, from the exit location you choose.

Nothing runs on your machine: there is no local browser to install, no driver to keep current and no model key to configure here. We supply the browser, the session lifecycle, the egress and a live view you can open and take over at any moment; the model stays with your client.

Endpoint

https://api.browser.lol/mcp

Transport

Streamable HTTP, stateless per request

Authentication

A Browser.lol API key in a request header

Plan

Premium, which carries programmatic access

Browsers

Any Chromium-family image your plan allows, Chrome by default

The key is what authenticates your assistant, and it carries the plan and the account behind it. Create one in your dashboard: it is shown a single time, so copy it straight into your client.

Use one key per client, machine or pipeline. Deleting a key stops that client immediately and nothing else, including in the middle of a conversation.

Pick your client, put the configuration in and swap YOUR_API_KEY for the key you just created. The same key works everywhere, so a second machine only needs this step.

claude mcp add --transport http browserlol https://api.browser.lol/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

{
  "mcpServers": {
    "browserlol": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote", "https://api.browser.lol/mcp",
        "--header", "Authorization:Bearer YOUR_API_KEY"
      ]
    }
  }
}

{
  "mcpServers": {
    "browserlol": {
      "url": "https://api.browser.lol/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

{
  "mcpServers": {
    "browserlol": {
      "type": "http",
      "url": "https://api.browser.lol/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Restart the client afterwards, so it picks the new server up. Nothing else is installed: the browser lives on our side.

Ask for something

Give your assistant a task that needs a browser. It opens the session itself:

Open example.com in a Browser.lol browser and tell me what the page says.

Every tool is named browser_* and answers with structured results. An assistant can start straight at browser_navigate: a session opens for it and it gets back an accessibility snapshot whose ref ids all the other tools act on, which is cheaper and far more precise than working from screenshots.

How the sessions behave

• Sessions create themselves. The first page tool opens one when your key has none running. With more than one running, a call without a session id is refused rather than guessed at.
• Sessions end themselves. A session ends on its own once nothing is driving it, and in any case after its maximum runtime. Closing it yourself frees the slot immediately.
• People and agents share one account. Your assistant can list, drive and close the sessions you started in the app, and you can do the same with its own.
• Reach stops at your account. Every tool works on your own sessions only. Nobody else's sessions are visible or reachable through the server.
• Programmatic access is a plan feature. Without Premium every call answers with an upgrade notice instead of a tool result.

• An API key is a credential: keep it in your client's secret store or an environment variable, never in a shared config file or a link, and delete it the moment it slips out.
• The key travels in a request header. Keep it out of URLs, where it would land in browser history, proxy logs and analytics.
• Pages load in our infrastructure, never on the machine running the assistant and never in a browser profile of yours: every session is a throwaway container.
• An agent's session is as visible as your own: you can watch it live and end it by hand at any moment.