Skip to main content
Use MCP when a coding-agent host should operate a Webcompute browser.

​
Setup

web mcp setup codex --surface runtime
Run the server directly when you need the stdio process: 
web mcp run
web mcp setup can render host config for supported targets such as codex, claude, cursor, opencode, and devin. Use web mcp config <target> to inspect the config without writing it.

​
Runtime tools

The default runtime surface exposes:
ToolUse it for
manage_browsersCreate, list, inspect, status, stop, resume, close, Debug UI URL, CDP URL, and CAPTCHA status.
execute_playwright_codeRun browser work on the active page and receive result, status, and bounded observation.
Use runtime tools when the host should plan each browser step. Runtime mode is best for deterministic browser control. execute_playwright_code receives a scoped page; snippets should use that page instead of redeclaring it or creating ordinary extra pages.

​
Runtime loop

Ask a coding agent to use Webcompute like this: 
1. Create or reuse a browser with manage_browsers.
2. Navigate or inspect with execute_playwright_code.
3. Read the returned result, logs, status, artifacts, and observation.
4. Run another small Playwright snippet.
5. Retrieve Debug UI, CDP, files, downloads, or recordings only when needed.
6. Close the browser when the task is done.
Good snippets are short and return values explicitly: 
execute_playwright_code({
  code: "await page.goto('https://example.com'); return { title: await page.title(), url: page.url() };"
})
Use Playwright locators such as getByRole, getByLabel, and getByText for interaction. Use the returned observation to decide the next snippet.

​
Agent mode

Optional agent mode adds:
ToolUse it for
run_web_agentDelegate a whole browsing goal to Webcompute’s model-backed browser-agent harness.
web mcp setup codex --surface all --model browsing
run_web_agent is available only on the agent or all surface. Use it only when the user explicitly wants Webcompute to handle the browsing goal. Saved model profiles and WEBCOMPUTE_MODEL_PROFILE affect MCP only through this tool. Current MCP tool schemas do not expose custom proxy creation options. Create proxied browsers through the SDK, CLI, or REST API first when proxy routing is required.

​
Policy at startup

web mcp run can apply an operator-owned browser policy to MCP-created browsers: 
web mcp run --allow-domain sec.gov --private-access localhost
This policy is applied when MCP creates browsers through manage_browsers. It is not a per-tool proxy setting.

​
Example host prompt

Create a Webcompute browser, open https://www.sec.gov/edgar/search/, find Apple's latest 10-Q filings, return filing date, accession number, and filing URL, then close the browser.
Debug UI and CDP URLs returned through MCP are signed bearer capabilities. Do not paste them into untrusted prompts or shared transcripts.
Reference: for coding agents, MCP tool reference, agent contract, SDK browser reference, and proxy reference.