Skip to main content
Glama
AceAtDev

ascended-browser

by AceAtDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

browser_flow

Record verified browser actions, save them as a reusable flow, then replay on a new page with variables to repeat tasks like submitting forms without model calls between steps.

Instructions

Record and replay browser work. Every verified browser_act on a tab is recorded (targets by what they are, not by ref; passwords and other secrets never). After a task succeeds once, action=save turns that tab's recorded steps into a flow; action=run replays it on a tab with no model call between steps, re-finding each element on the live page, so repeating the task (the next job application on the same site, the next record in the same form) takes seconds. Pass start_url for the new page and variables for the values that change; save reports the detected variables. A run stops at the first step it cannot find unambiguously or verify, and says which steps are done and which remain; finish that step yourself, then run again with from_step. The same review and authority apply to a replayed submit as to one you click yourself: run only a flow whose steps the user's request covers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNosave: a short name, e.g. 'Apply on careers.example.com'.
actionYesrecorded: numbered verified steps on tab_id so far. save: store them (or from_step..to_step) as a flow. list: saved flows. show: one flow's steps and variables. run: replay flow_id on tab_id. delete: remove flow_id.
tab_idNorecorded, save, run: the tab.
flow_idNoshow, run, delete: from save or list.
to_stepNosave: last recorded step to include (default: the latest).
from_stepNosave: first recorded step to include (default 1). run: step to resume from after finishing a stopped step yourself.
start_urlNorun: page to start on, e.g. the next job's apply page. Omit to start where the flow was recorded, or on the current page when the tab is already there.
variablesNorun: values for this run by variable name, e.g. {"email": "a@b.com"}. Unnamed variables keep the recorded value; an unknown name is an error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: secrets are never recorded, targets are stored by identity not ref, replayed steps involve no model call, elements are re-found live, and a run halts at the first unverifiable step and reports done/remaining with from_step resume. This is exactly the behavioral context an agent needs before invoking a replay tool.

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 purpose is front-loaded and every sentence contributes information (recording rules, save/run semantics, variable handling, stop/resume behavior, authority constraint). It is dense and fairly long, but there is no filler or repetition.

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

Completeness4/5

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

For an 8-parameter, no-annotation, no-output-schema tool, the description covers the important behavioral ground including failure/resume semantics. The main remaining gap is that it doesn't describe what recorded/list/show return, though those are read-only inspection modes where the schema enum hints at intent.

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 already 100%, so the baseline is 3; the description nonetheless adds value by explaining the record->save->run lifecycle, what start_url means for a new page, what variables carry, and that save reports detected variables. It doesn't elaborate on from_step/to_step beyond what the schema already documents.

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 opening sentence names a specific verb+resource ('Record and replay browser work') and the body specifies that recording happens from verified browser_act steps, which cleanly distinguishes it from siblings like browser_act and browser_open. An agent can tell what this tool is for without opening the schema.

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

Usage Guidelines4/5

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

It gives concrete trigger conditions ('After a task succeeds once, action=save... action=run replays it') and a real-world motivation (next job application, next record in the same form). It also states a usage boundary ('run only a flow whose steps the user's request covers'), though it never explicitly names a sibling alternative for one-off actions.

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

Deploy Server

Other Tools