Skip to main content
Glama
dontpayfull

AInotate

by dontpayfull
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

capture_web

Screenshot a web page in a headless browser and measure named elements, returning a PNG, exact rects and a spec stub for annotating web UIs.

Instructions

Screenshot a web page in a headless browser (Playwright) and measure named elements, so you can annotate with exact rects. Use it for web UIs; for desktop apps use capture_window, for what is on screen right now capture_screen. Pass url to load a page, or cdp_url + page_url_contains to attach to a browser that is already running and logged in (the tab is captured as is). Loads the page over the network; actions (click, fill) run in that page and can change state on the site, so only pass actions the user asked for. Presets: laptop 1280x800@2, wide 1600x1000@2, phone 390x844@3. Needs ainotate[web] and a Playwright browser (doctor checks). Returns the PNG path (temp folder), rects in CSS px, scale (use it as the spec scale), missing targets with the reason, a spec stub and a preview with the rects outlined.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoPage to load (http/https). Omit when attaching with cdp_url.
presetNoViewport: "laptop" 1280x800@2, "wide" 1600x1000@2 or "phone" 390x844@3.laptop
actionsNoSteps run in the page before the capture, in order: {"click": T}, {"fill": T, "value": "..."}, {"wait": T}, {"scroll_to": T}, {"wait_ms": 500}; T is a target as in targets.
browserNoEngine to launch: "chromium" (default), "firefox" or "webkit".chromium
cdp_urlNoDevTools address of a running browser to attach to, e.g. http://127.0.0.1:9222; captures its logged-in tab instead of launching a new browser.
targetsNoNamed elements to measure: {"name": {"text": "Checkout"} | {"selector": "css"} | {"role": "button", "name": "Save"}}, each with optional "within", "nth" (0-based), "exact", "fit".
full_pageNoCapture the whole scrollable page instead of the viewport.
timeout_msNoTime limit in ms for loading and for each action or target.
hide_overlaysNoHide cookie banners and similar overlays before the capture and after each click.
user_data_dirNoBrowser profile folder to reuse (cookies, logins) when launching.
page_url_containsNoWith cdp_url: substring of the URL of the tab to capture.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.1.1
    • addedInput schema / properties / actions / description
      Added value: +"Steps run in the page before the capture, in order: {\"click\": T}, {\"fill\": T, \"value\": \"...\"}, {\"wait\": T}, {\"scroll_to\": T}, {\"wait_ms\": 500}; T is a target as in targets."
    • addedInput schema / properties / browser / description
      Added value: +"Engine to launch: \"chromium\" (default), \"firefox\" or \"webkit\"."
    • addedInput schema / properties / cdp_url / description
      Added value: +"DevTools address of a running browser to attach to, e.g. http://127.0.0.1:9222; captures its logged-in tab instead of launching a new browser."
    • addedInput schema / properties / full_page / description
      Added value: +"Capture the whole scrollable page instead of the viewport."
    • addedInput schema / properties / hide_overlays / description
      Added value: +"Hide cookie banners and similar overlays before the capture and after each click."
    • addedInput schema / properties / page_url_contains / description
      Added value: +"With cdp_url: substring of the URL of the tab to capture."
    • addedInput schema / properties / preset / description
      Added value: +"Viewport: \"laptop\" 1280x800@2, \"wide\" 1600x1000@2 or \"phone\" 390x844@3."
    • addedInput schema / properties / targets / description
      Added value: +"Named elements to measure: {\"name\": {\"text\": \"Checkout\"} | {\"selector\": \"css\"} | {\"role\": \"button\", \"name\": \"Save\"}}, each with optional \"within\", \"nth\" (0-based), \"exact\", \"fit\"."
    • addedInput schema / properties / timeout_ms / description
      Added value: +"Time limit in ms for loading and for each action or target."
    • addedInput schema / properties / url / description
      Added value: +"Page to load (http/https). Omit when attaching with cdp_url."
    • addedInput schema / properties / user_data_dir / description
      Added value: +"Browser profile folder to reuse (cookies, logins) when launching."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations it discloses that the page loads over the network, that actions run in-page and can change state on the site (with a caution to only run user-requested actions), and that it requires ainotate[web] plus a Playwright browser verified by doctor. This is meaningful extra context, and it is consistent with readOnlyHint=false and openWorldHint=true.

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 purpose, then alternatives, then usage paths, then requirements, then return values. It is dense and slightly packed, but nearly every clause carries actionable information and nothing is redundant with structured fields.

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?

Although there is no output schema, the description spells out what is returned (PNG path in temp folder, rects in CSS px, scale to use as spec scale, missing targets with reasons, spec stub, preview with outlined rects). Nothing an agent needs to invoke and interpret the call is missing.

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 the baseline is 3, but the description adds integration-level semantics: the url-or-(cdp_url + page_url_contains) attach flow, the preset values, and the fact that actions execute before capture. This meaningfully complements the schema beyond field-level docs.

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+resource with scope: 'Screenshot a web page in a headless browser (Playwright) and measure named elements... so you can annotate with exact rects.' It explicitly distinguishes itself from siblings capture_window (desktop) and capture_screen (screen).

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 ('for web UIs') and when-not with named alternatives ('for desktop apps use capture_window, for what is on screen right now capture_screen'). It also disambiguates the url vs cdp_url attach paths and warns to only pass user-requested 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