Skip to main content
Glama

events

DestructiveIdempotent

Manage named instants in video recordings: import recorder JSON, add markers manually, resolve their addresses, and locate where each one plays after cuts.

Instructions

Named instants in a recording — the anchors a screen recording has instead of words.

An event is (name, seconds into the clip's own recording): sent, typing_started, a keystroke. No clip_id counts every clip's; clip_id alone lists one clip's, each with the address other tools take (name, or name#k when the name repeats, k from 0); event resolves one address and echoes three neighbours either side.

source imports a recorder's JSON and REPLACES the clip's events of the names it brings (other names are kept), so a repeat import is a no-op and a marks file and a keystroke file combine. A recorder usually logs wall-clock stamps: pass origin naming the key that holds the recording's start. A set with any event outside the clip is refused whole, because a wrong clock moves every event by the same amount. name + at adds one event by hand.

Events index the source, so no cut invalidates one; locate with event= says where one plays now, and present: false means it was cut.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoSeconds into the recording for the one event being added.
nameNoWith `at`, the event to add. With a bare-list `source`, what those times are. One token, no '#'.
pathNoThe project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing.
planNoResolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it.
clearNoRemove every event on this clip.
eventNoResolve one address — `name`, or `name#k` when the name repeats — and echo it with its neighbours, writing nothing.
offsetNoSeconds subtracted from every imported time, after `origin`.
originNoA key in the imported object holding the recording's zero, subtracted from every time — a recorder's clock is usually the wall clock.
sourceNoA recorder's event file to import: a JSON object of name → seconds (or → a list of seconds), or a bare list of seconds with `name`. Replaces this clip's events of the names the file brings; other names are kept.
clip_idNoThe clip whose events to read or write. Omit it to count every clip's.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.36.0

TDQS

A4/5.0
Behavior5/5

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

It clearly discloses destructive behavior (`REPLACES`, `clear` implied, outside-clip sets refused whole), idempotency (repeat import is a no-op), and the indexing guarantee that cuts do not invalidate events. This goes well beyond the annotations, which only flag idempotent and destructive hints, and it contradicts none of them.

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?

The description is dense and every sentence carries substantive information, but some phrasing is terse and awkward ('No `clip_id` counts every clip's; `clip_id` alone lists one clip's, each with the `address` other tools take'). It is compact without being bloated.

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?

Given the 10-parameter schema, output schema, and annotations, the description covers the critical operation modes, import semantics, edge cases, and cut-index behavior. It omits mention of `clear`, `plan`, `path`, and `offset`, but the schema fully documents those, so the overall calling contract is adequately complete for an agent.

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, and the description adds meaningful context beyond the schema: repeat imports no-op and combine named groups, an entire set is refused if one event is outside the clip, and events survive cuts without invalidation. It does not fully elaborate every parameter (e.g., offset and plan are left to the schema), but it enriches the core semantics.

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 identifies events as named instants (name + seconds) and enumerates the main operations: count/list, resolve, import, and hand-add. It is clear about the resource, though the first sentence is a metaphor rather than a specific verb phrase, and it never states a single overarching action like 'manage events'.

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?

The description gives concrete usage patterns: omit clip_id to count, use clip_id to list, use event to resolve, use source to import, and use name+at to add. It does not explicitly contrast with sibling tools, only pointing to `locate` for checking where a cut event plays now, leaving some when-to-use guidance implicit.

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