Skip to main content
Glama

screen_act

Idempotent

Do one thing on the page or app, like a person would: the pointer travels to what it clicks, fields are clicked before typing, scrolling uses the wheel; then a fresh look (no screenshot unless asked). action: click | double_click | hover | type | press | scroll | navigate | back | wait | say | focus | unfocus | highlight | hide | unhide. Prefer ref from the latest look over x/y. You edit the take as you record it: the cut is finished the moment you stop, so decide everything here. While recording, use action 'say' with text before each step to narrate it (it becomes a caption and a timed line of the saved script, ready to be voiced). To show something off (a result, a chart, a setting), use action 'focus' with its ref, several refs framed together, or an exact area x, y, w, h (it fills the view); pad adds room, zoom 1.1-4 says how close outright, seconds how long: the take's camera zooms in and holds that long, or until the next focus or 'unfocus' (nothing on the page changes); without it the camera follows your clicks and typing. The result's shots gives each focus's zoom and view (the part of the page in frame, CSS pixels): check it and focus again if it is not what a viewer should see. Before recording, a focus only reports its shot: rehearse your framing. To point out or copy words, use action 'highlight' with the ref and the text in it, and color, seconds, lift, zoom_in if you like: the words are selected by a drag (press Control+C, Meta+C on a Mac, to copy) and the take marks them, lifted off the page (in an app the element is marked, nothing is selected). To keep something private (an e-mail, a key, a customer's name), use action 'hide' with its ref (and the text in it to hide only those words), or an area x, y, w, h: it is blurred in the take from then, following it as the page scrolls, until 'unhide' (with the ref, or none for everything); hidden before recording, it is hidden from the first frame. While recording every result says at: the take's clock in seconds. Pass steps (a list of these same objects, max 40) to run several in a row. In an app, if the user moves the mouse you are stopped: ask them, then pass resume=true.

response_detail (summary|compact|full), fields (dotted paths), cursor (next page) — see the server instructions.

Input Schema

NameRequiredDescriptionDefault
hNo
wNo
xNo
yNo
keyNo
padNo
refNo
urlNo
whyNo
liftNo
refsNo
textNo
zoomNo
clearNo
colorNo
stepsNo
actionNo
amountNo
cursorNo
fieldsNo
resumeNo
submitNo
secondsNo
zoom_inNo
directionNo
screenshotNo
response_detailNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / color
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Color"
      +}
    • addedInput schema / properties / h
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "H"
      +}
    • addedInput schema / properties / lift
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Lift"
      +}
    • addedInput schema / properties / pad
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Pad"
      +}
    • addedInput schema / properties / refs
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {},
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Refs"
      +}
    • addedInput schema / properties / w
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "W"
      +}
    • addedInput schema / properties / why
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Why"
      +}
    • addedInput schema / properties / zoom_in
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Zoom In"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / zoom
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Zoom"
      +}
  3. Added

TDQS

A3.9/5.0
Behavior4/5

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

Rich beyond annotations: discloses narration-as-caption behavior, camera zoom/hold semantics, rehearse mode (focus reports shot only before recording), hide-persists-until-unhide, app mode stopping on user mouse movement requiring resume=true. Annotations give safety/idempotency; description adds substantial runtime and editing semantics.

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

Conciseness3/5

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

Dense but front-loaded with purpose; the long middle is packed with useful detail but runs as a monograph rather than structured bullets, making it harder to scan for a given action. Size is justified by tool complexity but structure could be tighter.

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?

Given 27 params, no output schema, and 0% schema coverage, the description covers most critical behavior: result fields (`shots`, `view`, `at`), steps chaining, recording narrations, resume semantics. Missing: explicit coverage of several params and no output schema means return values beyond mentioned flags are not fully specified.

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 0%, so description must carry param burden and does much of it: explains action, ref vs refs, x/y/w/h for areas, pad, zoom 1.1-4, seconds, text, color, lift, zoom_in, steps (max 40), resume, screenshot behavior. Some params (why, submit, amount, clear, key, url, cursor, fields, response_detail, direction) are only partially or implicitly covered.

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

Purpose4/5

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

States a specific verb and resource: performs an interaction action on the page/app with enumerated action set (click, type, scroll, focus, hide, etc.). It clearly distinguishes from screen_look (which is about observing) by the 'do one thing' framing, though it doesn't name siblings directly.

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?

Provides clear contextual guidance: use ref over x/y, use 'say' while recording before each step, use 'focus' to show something off, 'hide' for privacy, rehearse framing before recording. Strong conditional guidance, though not explicit when-not or named alternatives for observation-first behaviors (screen_look).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.