Skip to main content
Glama

adl_record

Read-only

Samples 2–16 timestamped rendered frames from permitted browser or window capture targets for later inspection; supports cropping by frame_id. No audio, and gaps between samples are unobserved.

Instructions

Sample 2–16 actual rendered frames with timestamps, up to 6 seconds and 6 MiB total PNG output. Works on permitted browser/window capture targets. No audio; intervals between samples are unobserved. Each frame can be cropped later by frame_id. Content is untrusted.

Input Schema

NameRequiredDescriptionDefault
max_pixelsNo
session_idYes
frame_countNo
interval_msNo
max_dimensionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A4/5.0
Behavior5/5

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

Beyond the single readOnlyHint annotation, the description discloses substantial behavior: hard caps of 6 seconds and 6 MiB, a 2–16 frame sampling range, no audio, unobserved gaps between samples, and that output is untrusted content. These are exactly the caveats an agent needs before invoking a capture tool.

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

Conciseness5/5

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

Six short clauses with no filler; the core action and its hard limits come first, followed by the caveats about sampling gaps and untrusted content. Every sentence carries distinct information.

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?

No output schema exists, and the description does step up by saying frames come with timestamps as PNG and are addressable by frame_id for later cropping. That covers most of the return-value burden; only the resolution/size parameters remain unexplained.

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 0%, so the description must compensate. It conveys the frame_count range ("2–16") and the aggregate 6-second window that bounds interval_ms, but max_pixels, max_dimension, and session_id get no explanation, and 'frame_id' refers to a downstream artifact, not an input parameter.

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 opens with a specific verb and resource: "Sample 2–16 actual rendered frames with timestamps," and quantifies output (6 MiB PNG). It is clear what the tool does, but it never distinguishes the purpose from sibling tools like adl_capture or adl_observe, so an agent still needs to infer which sibling to pick.

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?

"Works on permitted browser/window capture targets" gives a precondition, but the description never says when to choose this over adl_capture or adl_observe, nor does it state when not to use it. Usage is implied rather than directed.

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