Run a browser agent over MCP

What is the Twin MCP server?

It is a standards-compliant MCP server that exposes three tools — run (execute a goal), compile_skill (compile a reusable skill), and run_skill (replay a compiled skill by id). An MCP client lists these tools to its model automatically, so the agent can decide to use a browser the same way it decides to read a file.

How do I connect it?

Add the Twin MCP server to your client's MCP config with your Bearer key. The example below is the canonical JSON shape used by Cursor, Claude Desktop, Claude Code, and Cline.

{
  "mcpServers": {
    "twin-browser": {
      "url": "https://twin-browser.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_TWIN_API_KEY" }
    }
  }
}

What can the agent do once it is connected?

The model can now call the three tools by name. A typical session: call run to accomplish a goal, then compile_skill to make it reusable, then run_skill on later sessions to replay it deterministically.

• run — "go to this URL and accomplish this goal", returns structured output.
• compile_skill — turn a successful run into a parameterized, reusable skill.
• run_skill — replay a compiled skill by id with zero LLM planning calls.

How does cost stay flat in an editor workflow?

The same compile-once economics apply. The first time you ask your editor agent to do a web task it compiles a skill; the next time, run_skill (or a dispatch match) replays it with no planning call. So an agent you use dozens of times a day does not bill you the planner every time.

What about authorization and secrets?

Every MCP call carries your Bearer key, and the target URL is the authorization signal — auth, billing, and audit logging run on every call. Logins come from the credential vault by reference, never from the editor or the model context, and the backend enforces default-deny RLS per tenant.