Skip to main content
Glama

web_act

Open a URL, run ordered browser actions, and return the final page as Markdown in one shot. Use for scripted clicks, typing, scrolling, waits, and verification.

Instructions

Open a URL in a browser, run a list of actions and return the resulting page. One shot with no session: for several steps on one login or cart use browser_open + browser_do. Take a web_snapshot first and name elements by ref. Actions: click, type, fill, press, hover, select, scroll (until:'stable' loads everything), wait, eval, goto, verify, console, screenshot, hold; each is an object with do and the fields it needs. Returns per-action results and the final page as markdown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page to open first.
tierNoBrowser tier: browser, stealth, real (default), warm.
proxyNoProxy URL for this run only; web_route sets one per domain.
actionsYesSteps, in order, e.g. `[{"do":"type","ref":"e3","text":"shoes"},{"do":"press","key": "Enter"},{"do":"wait","selector":".results"}]`.
profileNoProfile saved by web_login whose cookies to use.
timeoutNoTimeout in ms for the whole interaction. Default 90000.
extractionNomarkdown (default), text, or html for the final page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.3

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the general safety profile is partly covered. The description adds important session behavior ('one shot with no session'), the action repertoire, and return shape, but does not detail side effects, auth, or failure modes.

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?

Front-loads the purpose and the key alternative before listing action types. The action list is dense but necessary; overall it is appropriately sized, though it could be slightly more scannable.

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 a complex browser-automation tool with no output schema, the description covers the one-shot limitation, snapshot prerequisite, action types, and return format. It omits error handling and some environment details, but the full schema and annotations cover much of the remaining context.

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 baseline is 3 even with no parameter info in the description. The description reinforces action structure and ref workflow, but adds little meaning beyond what the schema already documents for url, actions, tier, proxy, profile, timeout, and extraction.

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: opens a URL, runs actions, and returns the resulting page. It explicitly distinguishes itself from browser_open + browser_do for multi-step sessions, so an agent can tell it apart from siblings.

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?

Gives explicit when-to-use and when-not-to-use guidance: one-shot with no session, and for several steps on one login or cart use browser_open + browser_do. Also instructs taking a web_snapshot first and naming elements by ref.

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