Skip to main content
Glama
TMHSDigital

Screencast MCP

by TMHSDigital
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

read_events

Read a recording's input event log—mouse clicks, scroll, cursor moves, shortcuts, typing bursts with video timestamps and pixel positions. Filter by time range and event type, then sample frames at those moments.

Instructions

Read the input event log of a recording made with start_recording events: true: mouse clicks, scroll, cursor positions, shortcuts, and typing bursts, each with its video time in seconds and position in video pixels. Filter by time range and type, e.g. types: ['down'] for the clicks, then sample_frames at those times.

Input Schema

NameRequiredDescriptionDefault
toNoOnly events at or before this video time, in seconds.
fromNoOnly events at or after this video time, in seconds.
inputNoOr a recording path (its sibling .events.jsonl is read) or the .events.jsonl itself.
limitNoMost events to return (default 200); the result says when more matched.
typesNoOnly these types: down / up (mouse buttons), move (sampled cursor), wheel, key (a named shortcut), typing (a burst of typing: start and length only), gap (events may be missing). Clicks are down.
sessionIdNoSession id of a recording started with events: true.
inFrameOnlyNoDrop events whose cursor was outside the recorded area.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.39.0
    • changedInput schema / properties / types / description
      Previous value: -"Only these types: down / up (mouse buttons), move (sampled cursor), wheel, key. Clicks are down."New value: +"Only these types: down / up (mouse buttons), move (sampled cursor), wheel, key (a named shortcut), typing (a burst of typing: start and length only), gap (events may be missing). Clicks are down."
    • changedInput schema / properties / types / items / enum
      Previous value: -[
-  "down",
-  "up",
-  "move",
-  "wheel",
-  "key"
-]New value: +[
+  "down",
+  "up",
+  "move",
+  "wheel",
+  "key",
+  "typing",
+  "gap"
+]
  2. First observedv0.32.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the load and does well: it discloses the returned fields (time in seconds, position in video pixels), that typing bursts expose only start and length, and that 'gap' means events may be missing — a genuine data-quality caveat. It doesn't state what happens when the recording was not started with events: true or how the two input forms (sessionId vs path) interact, which keeps it below 5.

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?

One front-loaded sentence with the resource first and no filler; every clause carries information (content list, units, filter example, next step). It is dense and colon-heavy, which makes it slightly harder to scan than it could be, but nothing is wasted.

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 7-parameter, no-required, no-output-schema tool it covers the essentials: what is read, both input forms, filtering axes, the default limit via schema, and the follow-up tool. Remaining gaps are edge behavior — empty/absent event logs, and sessionId vs path precedence — which are minor but not trivial for a data-ingestion tool.

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 schema already defines from/to/limit/types/input/inFrameOnly; the description still adds value by giving a worked example of the types filter ('down' for clicks) and by tying the returned times to sample_frames, clarifying the unit/coordinate alignment the schema leaves implicit.

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 ('Read the input event log of a recording') and enumerates exactly what is returned: mouse clicks, scroll, cursor positions, shortcuts, typing bursts, each with video time and pixel position. It anchors the source to 'start_recording events: true', which separates it from sibling readers like player_frames or sample_frames.

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?

Gives concrete usage context ('Filter by time range and type, e.g. types: ['down'] for the clicks') and routes the agent forward to sample_frames at those times, establishing the read-events-then-look workflow. It stops short of stating when not to use it (e.g. no event log exists), but the intended context is unambiguous.

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