Skip to main content
Glama

events

DestructiveIdempotent

Manage named instants in a recording clip: import recorder JSON, add or remove anchors, resolve addresses, and list by clip or across clips.

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; name + time adds one at whatever plays that many seconds into the edit, clip read off the timeline. remove drops one by address. A bookmark event is what the web ruler draws.

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

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.
timeNoSeconds into the edit for the one event being added, instead of `at`: the clip and source instant are whatever plays there.
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.
removeNoDrop one event by address (`name` or `name#k`).
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

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.44.0
    • addedInput schema / properties / remove
      Added value: +{
      +  "default": null,
      +  "description": "Drop one event by address (`name` or `name#k`).",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / time
      Added value: +{
      +  "default": null,
      +  "description": "Seconds into the edit for the one event being added, instead of `at`: the clip and source instant are whatever plays there.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
  2. Addedv0.36.0

TDQS

A4/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: `source` REPLACES only the names the file brings while keeping others (explaining why repeats are no-ops and matching idempotentHint), a set containing any out-of-clip event is refused wholesale, and events index the source so cuts never invalidate them. It also documents the `plan` dry-run and the `present: false` cut indicator. Nothing here contradicts the destructive/idempotent hints.

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

Conciseness3/5

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

Every sentence carries information, but the em-dash prose style and the absence of any per-parameter structure make a 12-parameter, six-mode tool harder to scan than it needs to be. The data-model framing('anchors instead of words') is front-loaded but the operational modes are buried mid-paragraph.

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?

An output schema exists, so return values need not be explained, and the description covers the read/write/import/remove modes and the source-indexing invariant adequately for a tool of this complexity. Minor gaps remain around how `clear` interacts with other parameters and what the `event` echo actually contains, but the core call-correctness information is present.

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 every parameter in the same terms the description uses (address syntax, origin/offset arithmetic, path binding). The description summarizes the model but contributes little parameter-level meaning the agent cannot read directly from the schema.

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 states a specific resource (named instants in a recording) and enumerates the operations it performs — count, list, resolve, import, add by hand or by timeline time, remove, clear. An agent can distinguish it from `locate`, `cue_add`, and other event-adjacent siblings, though the multi-mode nature means no single verb+resource headline emerges.

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?

Mode selection is spelled out: no `clip_id` counts every clip's, `clip_id` alone lists one, `event` resolves one address, `source` imports, `name`+`at`/`time` add, `remove` drops one. It also names `locate` with `event=` as the way to find where an event plays now. It stops short of explicit when-not guidance or sequencing prerequisites for the import/replace flow.

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