WebRun Browser Automation

Create browser session

create_session

Destructive

Create a persistent session in a real Chrome browser running in a WebRun cloud environment (docs.webrun.ai), for multi-step interactive work. Returns a sessionId for subsequent commands. With an initial task the browser may act on third-party websites immediately. Do NOT use this to run or test a saved workflow — use trigger_workflow instead: only a workflow run carries the workflow's own rules, tracking and memory, so a session run will behave differently.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	Session mode (default: default)
`task`	No	Initial task configuration
`model`	No	Optional model name or profile key (from global config). Falls back to the configured default.
`proxy`	No	Proxy configuration. WebRun-managed: { source: "WebRun", country: "GB" }. Custom: { source: "custom", type: "http"\|"socks", host, port, username?, password? }. Omit for no proxy. Social/messaging automation (WhatsApp, Telegram, Instagram, Facebook, X, LinkedIn, TikTok): prefer country = the country the user is in right now — recommend it and confirm the country with them first; a mismatch is the usual cause of refused logins and sessions that log out repeatedly.
`debugC`	No	Enable debug mode on the instance (default: false)
`policyId`	No	Policy ID to apply automation guardrails (domain restrictions, capability controls, LLM role). Optional.
`timezone`	No	IANA timezone name for the session, e.g. "America/New_York", "Europe/London", "Asia/Tokyo". Date/time-sensitive instructions (e.g. "tomorrow morning", "today", "in 2 hours") are interpreted in this timezone. Defaults to "UTC" when omitted.
`environmentId`	No	Environment ID for persistent profile session. Use list_environments to find available IDs. Without this, a disposable instance is used.
`reach_out_mode`	No	Controls proactive chat-platform messages (Telegram/WhatsApp/Slack/Discord/Teams) to bot users on the same environment. Default: "off" — no messages are sent unless this is set explicitly. "guardrail_only" forwards guardrail prompts (CAPTCHA/2FA/verification) to chat when the API caller is offline. "full" also forwards the task result on completion. Each bot user additionally filters by their own reachOutMode preference.

Output Schema

TableJSON Schema

Name	Required	Description
`taskId`	No	Task ID when an initial task was provided
`message`	No
`sessionId`	Yes	Session ID for subsequent commands
`streaming`	No	Endpoints for watching the running browser. Only liveViewURL is a web page — the other two are machine endpoints on a non-standard port.
`environment`	No	Environment this session is bound to, when one was requested

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 2, 2026

changedInput schema / properties / proxy / description

Previous value: -"Proxy configuration. WebRun-managed: { source: \"WebRun\", country: \"GB\" }. Custom: { source: \"custom\", type: \"http\"|\"socks\", host, port, username?, password? }. Omit for no proxy."New value: +"Proxy configuration. WebRun-managed: { source: \"WebRun\", country: \"GB\" }. Custom: { source: \"custom\", type: \"http\"|\"socks\", host, port, username?, password? }. Omit for no proxy. Social/messaging automation (WhatsApp, Telegram, Instagram, Facebook, X, LinkedIn, TikTok): prefer country = the country the user is in right now — recommend it and confirm the country with them first; a mismatch is the usual cause of refused logins and sessions that log out repeatedly."

Changed4 schema fields changedAug 26, 2026

changedOutput schema / properties / streaming / description

Previous value: -"Live-view endpoints for the running browser"New value: +"Endpoints for watching the running browser. Only liveViewURL is a web page — the other two are machine endpoints on a non-standard port."

addedOutput schema / properties / streaming / properties / liveViewURL

Added value: +{
+  "description": "The live-view page. This is the ONLY URL to show a user or open in a browser. Null when the stream is unavailable — say live view is unavailable rather than offering another field.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / streaming / properties / webRTCURL / description

Added value: +"WHEP signaling endpoint for a programmatic WebRTC client. POST-only: a browser GET returns HTTP 405. Never show this to a user."

addedOutput schema / properties / streaming / properties / webViewURL / description

Added value: +"Direct MediaMTX player on the streaming host (port 2096), unbranded and often firewall-blocked. Debugging fallback only — prefer liveViewURL."

First observedAug 8, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond annotations by noting the session runs in a "real Chrome browser" in a cloud environment, returns a sessionId, and that "with an initial task the browser may act on third-party websites immediately." This complements the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=true). It does not contradict them. It could still mention that persistent sessions may need explicit cleanup/termination, but most safety-critical traits are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: core function, return value, unexpected side effect, and the caution about trigger_workflow. The sentences are front-loaded and concise, with no filler or redundancy. The more involved exclusion sentence is still clearly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, rich nested objects, a full input schema, annotations, and an output schema, the description supplies the essential decision-making context: what a session is, that it is stateful, that it may take real-world actions, and that it is not a workflow runner. Nothing critical needed for selecting or invoking the tool appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents each parameter. The prose does not need to repeat parameter details, and it does not add much semantics beyond what the schema provides. The schema itself already explains key nuances like proxy levels and timezone interpretation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific action and object — "Create a persistent session" — and clarifies the resource as "a real Chrome browser running in a WebRun cloud environment" for "multi-step interactive work." It also explicitly separates this from running a saved workflow, naming the sibling trigger_workflow as the alternative, which removes ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance ("for multi-step interactive work") and an explicit when-not-to-use rule with a named alternative: "Do NOT use this to run or test a saved workflow — use trigger_workflow instead." It also explains why the alternative is required: only a workflow run carries the workflow's rules, tracking, and memory, and a session run behaves differently.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All WebRun Browser Automation tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: ad-hoc tasks (browser_task), persistent sessions (create_session/send_task), workflows (create/get/update/trigger), agents (create/list/pause/resume), and session control (pause/resume/stop/terminate). The descriptions explicitly disambiguate overlapping-looking tools like browser_task vs trigger_workflow, making accidental misselection unlikely.

Naming Consistency4/5

The vast majority follow a clear verb_noun pattern (create_workflow, list_agents, pause_session_task, trigger_workflow, etc.). Minor deviations exist: browser_task and guardrail_response are noun_noun, and screenshot is a single word, but these are understandable and do not disrupt the overall pattern.

Tool Count3/5

With 21 tools the set is on the heavy side, fitting the 16-25 borderline range. Each tool has a distinct purpose, but the count feels slightly inflated due to granular session/task control (pause, resume, stop, terminate) and separate workflow/agent management that could potentially be consolidated.

Completeness3/5

Workflows have create/read/update/list/trigger coverage, and sessions/tasks have robust lifecycle control, but there are notable gaps: no delete_workflow or delete_agent, and agents lack update functionality. While core automation flows are supported, lifecycle management is incomplete without deletion or editing of scheduled agents.

Resources

Need Help?