Skip to main content
Glama

Check a recording request

estimate_recording
Read-only

Check a recording request without recording or using up any quota. Takes the same arguments as record_html. Returns what to fix (invalidIssues, limitIssues, capacity.reasons), the resource estimate, your limits and your usage: recordings in progress and recordings started in the last 24 hours.

Input Schema

NameRequiredDescriptionDefault
crfNoQuality for mp4 and webm, from 10 (best, largest) to 35 (smallest). Not together with bitrateMbps; not for gif.
fitNoHow the frame fills outputSize: fill (stretch), contain (letterbox in background) or cover (crop to fill).
fpsNoFrame rate: one of 15, 23.976, 24, 25, 29.97, 30, 59.94, 60 (default 30). For gif, a whole number from 1 to 30.
urlNoPublic http(s) URL of the page or creative to record. The recorder runs on the internet: localhost and private networks are out of reach. Pass url or html, not both.
cropNoRecord only this region of the viewport: { x, y, width, height } in pixels, even values, inside the viewport.
htmlNoA complete HTML document to record instead of a url, e.g. a banner you just wrote. One file: inline the CSS and JavaScript, and load images, fonts and libraries from public https URLs or data: URIs. It is published at an unlisted public URL and recorded from there.
loopNogif only: whether the gif loops.
syncNoHow trim markers are used: auto (default: markers when the page calls trim_start(), else the load event), load (ignore markers) or markers (fail when trim_start() is not called within markerWaitSec).
audioNoRecord the page’s audio too. Not for gif.
widthYesViewport width in CSS pixels: even, 16–7680. Use the creative’s size, e.g. 300 for a 300×250 banner or 1920 for a full HD page.
formatNomp4 (default, H.264), webm or gif.
heightYesViewport height in CSS pixels: even, 16–7680.
startAtNoWhere the video starts: "load" (default: the load event, or the first trim_start() call) or that many milliseconds after it (0–120000).
rendererNoauto (default), cpu or gpu. Leave it on auto.
backgroundNoLetterbox colour for fit: contain, as #rrggbb.
outputSizeNoScale the video to { width, height } (even values); see fit.
bitrateMbpsNoA target bitrate in Mbps (1–100) instead of crf, for platforms with a bitrate spec (e.g. DOOH). Not for gif.
bitrateModeNovbr (default) or cbr. Needs bitrateMbps.
durationSecYesLength of the video in seconds (1–300; your account limit applies). With trim_end() it is the maximum.
pixelFormatNoyuv420p (default; plays everywhere), yuv422p or yuv444p.
markerWaitSecNoHow long to wait for trim_start() after load, in seconds (0–60, default 10).
markerLatencyMsNoOverrides the measured delay between a marker call and the frame it marks (0–1000 ms). Rarely needed.

Output Schema

NameRequiredDescriptionDefault
okYes
usageYes
limitsYes
capacityYes
estimateYes
limitIssuesYes
invalidIssuesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / crop / properties / height / multipleOf
      Added value: +2
    • addedInput schema / properties / crop / properties / width / multipleOf
      Added value: +2
    • addedInput schema / properties / crop / properties / x / multipleOf
      Added value: +2
    • addedInput schema / properties / crop / properties / y / multipleOf
      Added value: +2
    • addedInput schema / properties / height / multipleOf
      Added value: +2
    • addedInput schema / properties / outputSize / properties / height / multipleOf
      Added value: +2
    • addedInput schema / properties / outputSize / properties / width / multipleOf
      Added value: +2
    • addedInput schema / properties / width / multipleOf
      Added value: +2
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Adds real behavior beyond readOnlyHint/openWorldHint: no recording happens and no quota is consumed, and it names the diagnostic buckets returned (invalidIssues, limitIssues, capacity.reasons) along with the resource estimate, account limits, and in-progress/24h usage counters. This tells the agent exactly what a failure looks like and why the call is free.

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 non-obvious facts (no recording, no quota) in the first clause and stays to three sentences. The trailing enumeration of return fields is largely redundant with the existing output schema, which is the only wasted text.

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?

For a 22-parameter tool with nested objects and an output schema, the description covers the essential unknowns: it is side-effect free, it accepts the same payload as the real record call, and it returns both a resource estimate and actionable issue lists. Return-shape detail is correctly left to the output schema.

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% across 22 richly documented parameters, so the baseline is 3. The description only adds that the argument set is identical to record_html's, which helps the agent reuse a payload but adds no per-parameter meaning.

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 ("Check a recording request") plus the crucial scope constraint that nothing is actually recorded or billed. It explicitly contrasts with the sibling record_html by saying it takes the same arguments, so an agent can tell dry-run from real run without opening a 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?

Implies the validate-before-record workflow by noting it consumes no quota and mirrors record_html's arguments, which is enough to route an agent that is unsure about limits or validity. It stops short of an explicit "call this before record_html" instruction or any statement of when it can be skipped.

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.

Resources