WebRun Browser Automation

Create workflow

create_workflow

Create a new saved workflow. READINESS BAR: if you could not execute the prompt yourself as a human in a browser — which site, which records, which fields, delivered where, matched to each recipient how — it is not ready; first collect the missing business facts from the user (see the TASK INTERVIEW in the server instructions), then create. Requires title and promptTemplate — write the prompt as a browsing runbook following the Goal / Ground rules / Stages / Output contract in the promptTemplate field description. For tasks that must handle each new item exactly once (new messages, forward once, skip seen), memoryContract is REQUIRED — three plain-English fields addressed to the agent: groundRules, memoryInstruction and itemIdentity (see the field descriptions); the platform wires the tracking itself — never write memory or tracking steps into the prompt. Created in the connection's environment automatically — omit environmentId and never ask the user to choose one. Write the user's concrete values (names, URLs, numbers) directly into the prompt; use {{variables}} ONLY when the user explicitly wants a reusable template with per-run inputs. Everything else is optional and defaults sensibly — do not quiz the user about settings. A supplied schedule is stored as a setting only — the workflow does not run on a timer until deployed via create_agent. To run or TEST the workflow, use trigger_workflow ONLY — never browser_task or create_session.

Input Schema

TableJSON Schema

Name	Required	Description
`flow`	No	Dashboard flow diagram: { trigger: {kind, phrase}, steps: [{ primary: {label, domain}, verb }] }.
`model`	No	Model profile key. Omit for the account default.
`proxy`	No	Proxy for runs. {source:"WebRun", country?} or {source:"custom", type:"http"\|"socks", host, port, username?, password?}. Custom passwords are encrypted at rest and never returned.
`title`	Yes	Workflow title (shown on the dashboard).
`memory`	No	The agent's private notebook: shown to it at the start of every run, updated automatically after each run. Seed it ONLY with durable facts the next run must already know — the exact description of a target item (e.g. the specific picture to match), user preferences, known starting state — one short line per fact. Do NOT put task steps here (promptTemplate) or tracking rules here (memoryContract). Most workflows need no seed at all: the agent builds its own notebook as it runs.
`skills`	No	Workflow-scoped skill entries (dashboard shape).
`trigger`	No	How the workflow is meant to be invoked (informational — see notes). Defaults to {type:'manual', source:'manual'}.
`listType`	No	Advanced — defaults automatically ('monitor' when memoryContract is supplied); leave unset.
`schedule`	No	Saved schedule setting. NOTE: record-only — the workflow does NOT run on a timer until deployed as a scheduled agent (dashboard or Telegram bot).
`timezone`	No	IANA timezone for runs of this workflow (e.g. "America/New_York").
`department`	No	Free-text department label (e.g. "inventory").
`outputType`	No	Output contract: 'text' (default), 'structured' (JSON matching outputSchema), 'structured_csv' (rows for the outputSchema column names).
`destination`	No	Result destination chip: { type, sub, description }. Types seen: 'custom-api', 'slack', 'sheets', 'email', 'messaging', 'telegram', 'crm'.
`startingUrl`	No	Page Chrome opens at the start of each run. Omit to let the prompt decide.
`useCaseTags`	No	Categorisation tags.
`fileDeferred`	No	Dashboard flag: file selection deferred to run time.
`outputSchema`	No	JSON Schema object (outputType "structured") or array of column-name strings (outputType "structured_csv").
`reachOutMode`	No	Proactive-chat policy for runs: 'off', 'guardrail_only', or 'full'. Omit (or pass null) to inherit the account default (MCP-initiated runs treat inherit as 'off').
`wizardPreset`	No	Dashboard wizard preset: { technology, useCases[], destination, destinationSub }.
`environmentId`	No	Rarely needed — OMIT it: the connection's bound environment (or your only environment) is applied automatically. Pass only when the user explicitly names a different environment. Never ask the user to choose.
`memoryEnabled`	No	Persist per-workflow agent memory across runs (default true).
`publicDraftId`	No	Dashboard public-draft correlation id.
`requiredFiles`	No	Per-run file attachments. Each row may name its own environmentId; ownership is enforced per-file at dispatch.
`roiHourlyRate`	No	Hourly rate for the ROI card.
`triggerPhrase`	No	Natural-language phrase that invokes this workflow in chat.
`memoryContract`	No	How this workflow should behave and what it must remember between runs. REQUIRED whenever the task handles each thing once — new messages, forward once, skip anything already done. Write all three fields in plain English, addressed to the agent; the platform wires the tracking itself. Never write any of this into the prompt: the prompt says what to do, this says how to do it consistently. To explicitly disable tracking for a task that looks like it needs it, pass {mode:'none'}.
`policyOptedOut`	No	Opt this workflow out of the environment's default policy.
`promptTemplate`	Yes	The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as "not stated", never estimate; keep a running tally and restate it every turn ("captured C items · written R rows"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). When a stage delivers per-recipient (message/email each customer), state the MATCHING RULE in that stage — the identifier shared by the source record and the destination recipient (e.g. the customer name exactly as written in the source, matched against the contact name) — and the no-match branch: skip it and report it, never deliver to a similarly-named near-match. Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no "check memory", "record in memory", "store in memory" steps): tracking is authored in memoryContract and WebRun applies it to every run automatically.
`refineMessages`	No	Dashboard builder refinement thread rows: [{ role, content }].
`variableValues`	No	ONLY for explicitly dynamic workflows: default values for {{variables}}, keyed by variable name. NOTE: applied only when triggering via MCP trigger_workflow (merged under caller-supplied variables); REST /trigger and bot triggers ignore this field.
`compatibleTools`	No	Sites/tools the workflow uses: [{ name, loginUrl, domain, role }].
`conciergeNotify`	No	Where the concierge announces results (e.g. 'Telegram', 'Slack', 'WhatsApp', 'Microsoft Teams', 'concierge').
`workListEnabled`	No	Advanced — set automatically when memoryContract is supplied; leave unset.
`deployedPolicyId`	No	Policy id to run under (must be owned by you).
`orchestrateFirst`	No	Discovery mode: one run gathers the WHOLE work list up front, later runs claim one item each.
`shortDescription`	No	One-line summary shown in workflow lists.
`roiMinutesPerTask`	No	Minutes saved per run (dashboard ROI card).
`templateVariables`	No	ONLY for explicitly dynamic workflows (the user asked for a reusable template): metadata for the {{variables}} used in promptTemplate (drives the dashboard fill-in UI). Omit entirely when the prompt carries concrete values.

Output Schema

TableJSON Schema

Name	Required	Description
`slug`	Yes
`notes`	No	Caveats the caller should relay (e.g. the schedule is record-only)
`title`	Yes
`success`	Yes
`nextStep`	No	How to run or test this workflow (always trigger_workflow)
`workflowId`	Yes
`environment`	No
`memoryContract`	No	Echo of the stored tracking contract (the three authored fields) — absent when the workflow has none

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only indicate non-read-only, non-destructive, non-idempotent. The description adds substantial behavioral context: schedule is stored as a setting only, not run until deployed via create_agent; the connection's environment is applied automatically; memoryContract wiring is platform-managed; variables are only used when explicitly requested. This goes beyond the sparse annotations and clarifies side effects and invocation semantics.

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

Conciseness4/5

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

The description is long but densely packed with essential guidance. It's front-loaded with the readiness bar and required fields, then flows logically through memoryContract, environment, variables, schedule, and testing. While it could be tightened, every sentence serves a purpose given the tool's complexity and 38 parameters; no filler or redundancy.

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?

For a tool with 38 parameters and nuanced usage rules, the description covers all critical aspects: required fields, prompt construction, memoryContract requirements, environment handling, variable policy, schedule semantics, testing routing, and what to avoid. The output schema exists separately, so return values need not be explained. An agent has enough to call this correctly without external lookup.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. However, the description adds crucial meaning for several parameters: it explains memoryContract's three fields and when it's required, clarifies environmentId should be omitted, prescribes the promptTemplate structure (Goal/Ground rules/Stages/Output contract), and distinguishes concrete values from {{variables}}. It also notes schedule only stores a setting. This is significant added value beyond the schema.

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?

States a specific verb and resource: 'Create a new saved workflow.' It differentiates from siblings by explicitly directing to trigger_workflow for testing and warning against browser_task or create_session. The description also clarifies what the workflow is not (not a timer until deployed).

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?

Provides explicit when-to-use guidance: only when readiness bar is met, requires title and promptTemplate, and collects missing facts first. Clearly states when to use trigger_workflow instead, and instructs to omit environmentId and not ask the user to choose one. Also explains when memoryContract is required, distinguishing from defaults.

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

A4/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: browser_task vs create_session differentiate one-off vs persistent sessions, trigger_workflow is explicitly separated from generic task execution, and the pause/resume/stop/terminate actions are scoped to either agents or session tasks. There is no overlap where an agent could mis-select between tools.

Naming Consistency4/5

The vast majority follow a consistent verb_noun pattern (create_, list_, get_, pause_, resume_, stop_, terminate_, trigger_, update_, send_). Two tools deviate: browser_task (noun_verb) and guardrail_response (noun), but these are minor and still readable within the overall convention.

Tool Count4/5

21 tools is on the higher end but justified by the domain covering three distinct resource types (sessions, workflows, agents) plus environments and status/guardrail handling. It is slightly heavy but each tool serves a clear purpose without redundancy.

Completeness3/5

Core lifecycle operations are covered for sessions (create, list, terminate, send task, pause/resume/stop task) and workflows (create, get, list, update, trigger). However, there are notable gaps: no delete operations for workflows or agents (only pause/resume for agents, and no delete_workflow), and no dedicated get_agent detail endpoint. These omissions could force agents to work around missing functionality.

Resources

Need Help?