Skip to main content
Glama
webEmbedding

webEmbedding

by jongko54

capture_reference_bundle

Capture a URL with a real browser to gather runtime HTML, screenshots, DOM/style summaries, assets, network/HAR data, and responsive breakpoints for page rebuild or verification.

Instructions

Capture evidence for a URL with a real browser: runtime HTML, full-page screenshots, DOM and computed-style summaries, assets, network/HAR metadata, interactions, and optional desktop/tablet/mobile breakpoints. With output_dir and capture_html it also writes an offline HTML snapshot. Use when you will build or verify a page yourself.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "capture_reference_bundle"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesPublic http(s) URL of the page to inspect, capture, or clone.
output_dirNoDirectory to write capture artifacts, generated files, and reports into; created if missing.
capture_htmlNoInclude the rendered runtime HTML in the capture.
license_textNoLicense or permission text that allows reusing the page, from the user or the site; informs the reuse/rebuild policy.
wait_secondsNoUpper bound in seconds for each browser readiness wait (load, network quiet, lazy-load scroll); capture continues as soon as the page settles.
user_data_dirNoPath to an existing Chrome profile directory, to capture a page behind a login the user owns. Omit for a clean session.
source_signalsNoExtra hints about the page's origin, e.g. ["framer", "spline", "export"]; merged with signals detected from the page.
viewport_widthNoPrimary browser viewport width in CSS pixels (default 1440).
exact_requestedNoTrue (default) when the user wants an exact, faithful clone; false when an approximate rebuild is acceptable.
timeout_secondsNoTimeout in seconds for the static HTTP fetch of the page.
viewport_heightNoPrimary browser viewport height in CSS pixels (default 1200).
capture_screenshotNoTake a full-page PNG screenshot (needed for visual verification).
storage_state_pathNoPath to a Playwright storage-state JSON (cookies, localStorage) to load before capture, for pages behind a login the user owns.
breakpoint_profilesNoExtra viewports to capture and verify: desktop (1440x1200), tablet (768x1024), mobile (390x844). Example: ["tablet", "mobile"].
include_runtime_traceNoLaunch a real browser for runtime capture (default true). False limits the result to static HTML inspection.
storage_state_output_pathNoPath to write the browser storage state after capture, so the session can be reused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv0.3.13
    • addedInput schema / properties / breakpoint_profiles / description
      Added value: +"Extra viewports to capture and verify: desktop (1440x1200), tablet (768x1024), mobile (390x844). Example: [\"tablet\", \"mobile\"]."
    • addedInput schema / properties / capture_html / description
      Added value: +"Include the rendered runtime HTML in the capture."
    • addedInput schema / properties / capture_screenshot / description
      Added value: +"Take a full-page PNG screenshot (needed for visual verification)."
    • addedInput schema / properties / exact_requested / description
      Added value: +"True (default) when the user wants an exact, faithful clone; false when an approximate rebuild is acceptable."
    • addedInput schema / properties / include_runtime_trace / description
      Added value: +"Launch a real browser for runtime capture (default true). False limits the result to static HTML inspection."
    • addedInput schema / properties / license_text / description
      Added value: +"License or permission text that allows reusing the page, from the user or the site; informs the reuse/rebuild policy."
    • addedInput schema / properties / output_dir / description
      Added value: +"Directory to write capture artifacts, generated files, and reports into; created if missing."
    • addedInput schema / properties / source_signals / description
      Added value: +"Extra hints about the page's origin, e.g. [\"framer\", \"spline\", \"export\"]; merged with signals detected from the page."
    • addedInput schema / properties / storage_state_output_path / description
      Added value: +"Path to write the browser storage state after capture, so the session can be reused."
    • addedInput schema / properties / storage_state_path / description
      Added value: +"Path to a Playwright storage-state JSON (cookies, localStorage) to load before capture, for pages behind a login the user owns."
    • addedInput schema / properties / timeout_seconds / description
      Added value: +"Timeout in seconds for the static HTTP fetch of the page."
    • addedInput schema / properties / url / description
      Added value: +"Public http(s) URL of the page to inspect, capture, or clone."
    • addedInput schema / properties / user_data_dir / description
      Added value: +"Path to an existing Chrome profile directory, to capture a page behind a login the user owns. Omit for a clean session."
    • addedInput schema / properties / viewport_height / description
      Added value: +"Primary browser viewport height in CSS pixels (default 1200)."
    • addedInput schema / properties / viewport_width / description
      Added value: +"Primary browser viewport width in CSS pixels (default 1440)."
    • addedInput schema / properties / wait_seconds / description
      Added value: +"Upper bound in seconds for each browser readiness wait (load, network quiet, lazy-load scroll); capture continues as soon as the page settles."
  2. First observedv0.3.12

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds substantially more, namely that a real browser is launched, that artifacts and an offline HTML snapshot are written to output_dir (created if missing), that support for authenticated capture is available via a Chrome profile or storage state, and that capture proceeds once the page settles. It does not state what is returned or how failures surface, but the write behavior and auth prerequisites are well disclosed and consistent with readOnlyHint=false.

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?

Three dense sentences, with the artifact inventory front-loaded and the usage condition at the end. The long enumeration is justified because it defines the tool's scope, and there is no filler, though the sentence could be easier to scan as a short list.

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 16-parameter capture tool with no output schema, the description enumerates the captured artifacts, which effectively stands in for return values, and it covers write destinations, auth paths, and responsiveness. The remaining gaps are whether results appear only on disk, where the report lives, and how partial failures are reported, but overall it is close to complete for the task.

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 schema already documents all 16 parameters, which sets a baseline of 3. The description does add one piece of cross-parameter meaning, namely that output_dir plus capture_html together produce an offline HTML snapshot, but it says nothing further about the many remaining parameters (license_text, exact_requested, source_signals, timeout behavior).

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?

The description names a specific verb (capture evidence) and an enumerated resource set: runtime HTML, full-page screenshots, DOM and computed-style summaries, assets, network/HAR metadata, interactions, and responsive breakpoints. It is clearly more comprehensive than a single-page read, but it never names a sibling such as inspect_url or clone_reference_url, so the agent must infer the boundary itself.

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

Usage Guidelines3/5

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

'Use when you will build or verify a page yourself' implies a build/verify scenario, which is genuine usage guidance, but it does not say when NOT to use it or which sibling to pick instead (inspect_url, audit_reference_url, clone_reference_url). The conditions that select this tool over those alternatives are left to inference.

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