Create or overwrite a reusable browser automation flow with a start URL, bounded actions, optional data extraction, saved profile, and cron schedule for recurring runs.
Create or overwrite a saved flow: optional profile, startUrl, bounded actions, optional extract and cron schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | ||
| name | Yes | Flow name (lowercase letters, digits, - and _). |
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| saved | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, and "create or overwrite" is consistent with that profile. The description adds useful scope detail (bounded actions, profile reuse, cron schedule) but never says what happens to an existing definition on overwrite or that the flow must exist elsewhere to be validated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler, listing the salient components. It is efficiently sized, though the comma-list style trades precision for brevity on a schema this complex.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, but the tool's input surface is enormous (15 action variants, nested extract config) and the description devotes a single clause to it. Key operational facts — the overwrite semantics, the 100-action cap, the name pattern, and whether the saved flow is runnable immediately — are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% at the top level, and the description enumerates the meaningful flow fields (profile, startUrl, actions, extract, schedule), which orients an agent inside a very large nested schema. It omits headless and timezone, and its flat phrasing ('optional profile') slightly obscures that these live under the nested flow object rather than as sibling top-level params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb pair ("create or overwrite") and a clear resource ("saved flow"), which separates it from flow_run (execute) and flow_list (enumerate) in the sibling set. It stops short of naming those siblings explicitly, so differentiation relies on inference from the word "saved".
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrasing "saved flow" and "create or overwrite" hints that this persists a definition for later execution by flow_run. There is no explicit statement of when to prefer this over flow_run/flow_list, no preconditions, and no warning about overwriting an existing flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.