Skip to main content
Glama

addAnnotation

Add text callouts, arrows, or blur masks over a span of an edited video timeline to label moments or hide private details.

Instructions

Add an annotation over a span of the edited timeline (virtual seconds). type picks what it is: 'text' (the default) for callouts, labels and titles; 'figure' for an arrow pointing at something; 'blur' for a privacy mask that blurs or pixelates what is under it, the way to hide an email address, a token, a password field or any private detail the recording shows. Image annotations are not available here: they need a file, added in the editor. x/y place the centre, 0–100 percent of the annotation's box (default the centre). Text and arrows sit on the output frame, the whole picture padding included, as the editor places them: zooms and padding never move them. A blur sits on the recording's picture instead, so x/y/width/height are percent of the recording and it stays on what it hides when padding or a zoom moves the picture. A text box is sized to its words and kept inside the frame; it is drawn on a dark plate by default, and fontSize, color, background, bold and animation set its look. An arrow or a blur takes width/height (default 30 × 20) and its own data: figureData {arrowDirection, color, strokeWidth} for an arrow, blurData {type 'blur' or 'mosaic', shape 'rectangle' or 'oval', color, intensity, blockSize} for a blur. The result reads the annotation back as getCurrentDocument reports it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
boldNo
textNo
typeNotext: words on the frame. figure: an arrow. blur: a privacy mask that blurs or pixelates what is under it, such as an email address or a token on screen.text
colorNoText colour, a CSS colour such as #ffffff.
widthNoBox width, in percent of the annotation's box: the output frame for an arrow, the recording's picture for a blur. Not for text, whose box is its words.
endSecYes
heightNoBox height, in percent of the same box as width.
blurDataNoA blur's look: type blur or mosaic, shape rectangle or oval, color of the mosaic grid, intensity, blockSize.
fontSizeNoText size; 32 is the editor's default, a title reads well at 56 to 80.
startSecYes
animationNoHow the text enters: typewriter types it out, pop springs it in, and so on.
projectIdNoThe project to act on, from listProjects. Omit it only for the project open in the OpenScreen editor, which works only while the app runs.
backgroundNoColour of the plate behind the text, or "none" for no plate.
figureDataNoAn arrow's direction, colour and stroke width.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description goes well beyond that, explaining that text/arrows are anchored to the output frame while a blur anchors to the recording's picture and stays put under zooms or padding. It also discloses the return convention ('the result reads the annotation back as getCurrentDocument reports it') and the projectId/editor-open caveat. It stops short of saying whether annotations can be removed or what permissions are needed.

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 action and the type taxonomy before diving into geometry and per-type data. Sentences are long and run together in places, but for a 16-parameter tool with nested objects the density is largely earned.

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 16-param mutation tool with nested objects and no output schema, the description covers type selection, coordinate frames, sizing defaults, styling fields, the projectId fallback, and the return shape. Nothing critical to calling it correctly is missing.

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 63%, so the description has to carry real weight, and it does: it explains the dual coordinate systems for x/y, gives width/height defaults (30 × 20) and their reference box per type, describes figureData/blurData contents, and notes fontSize defaults. Some of this repeats the schema's own field descriptions, but the placement semantics are added value the schema does not supply.

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?

States a specific verb (add) and resource (annotation) scoped to 'a span of the edited timeline (virtual seconds)', and enumerates the three annotation types with what each is for. It does not differentiate from the sibling setAnnotation, so an agent cannot tell from the text alone when to add versus update.

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?

Gives per-type usage context (blur for hiding an email, token or password field) and one exclusion ('image annotations are not available here: they need a file, added in the editor'). It never names setAnnotation or states a when-not condition relative to any sibling, so routing is only implied.

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