Skip to main content
Glama

add_marker

Add timestamped narration markers to screen recordings, with Clipy-verified assertions or driver-attested pass/fail evidence. Markers become transcript chapters.

Instructions

Drop a live-timestamped narration marker into the active recording session ('reproduced the bug', 'the fix renders correctly at mobile width'). Markers become the recording's transcript chapters, so narrate as you work — they are how the recording stays agent-readable despite having no audio. A mark can carry evidence in ONE of two provenances, never both. (1) CLIPY-VERIFIED — assertSelector (element must exist), assertText (that element must contain the text; requires assertSelector), assertUrl (glob on the live URL): Clipy itself checks the recorded page, so this is the strongest evidence. (2) DRIVER-ATTESTED — observed + verdict (both required together): you report what YOUR tooling saw and whether it passed. Clipy vouches only that you SAID it — it did NOT verify it — which is falsifiable against the recorded frames: weaker than clipy-verified, far stronger than plain prose. Use driver-attested when your agent drives its OWN browser/tooling while Clipy records (e.g. via mac-screen) or when there is no Clipy-owned page to assert against. The two lanes are rendered so the weaker one LOOKS weaker at a glance: clipy-verified marks lead with a verdict glyph ([assert ✓ verified-by-clipy; …] / [ASSERT ✗ verified-by-clipy; …]), while driver-attested marks lead with a HEDGE glyph instead ([≈ ASSERT driver-attested; observed=…] / [≈ FAILED driver-attested; observed=…]) — a skimming reviewer must never mistake an attestation for a verification. Failures are annotated into the mark as explicit FAILURES (never written as fact), tallied in their own segment of the recording's verification summary, and — with failMode 'abort' — discard the whole session. Marks default to the live recording clock; pass atSeconds to backdate one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesWhat is happening right now.
verdictNoDRIVER-ATTESTED outcome for `observed`. Requires observed. Mutually exclusive with assertSelector/assertText/assertUrl.
failModeNoOn a FAILED outcome (a clipy-verified assertion that failed, or a driver-attested verdict of 'fail'): 'warn' (default) records the failure and keeps recording; 'abort' discards the whole session (like abort_recording) and returns loudly. A pass never aborts; an unverified claim never aborts.
observedNoDRIVER-ATTESTED evidence: what YOUR tooling observed (e.g. 'HTTP 200, body contains orderId'). Requires verdict. Mutually exclusive with assertSelector/assertText/assertUrl — one provenance per mark.
assertUrlNoGlob the current page URL must match. `**` matches anything (including `/`); `*` matches within a path segment. e.g. 'http://localhost:3000/**/settings'.
atSecondsNoPlace the mark at this point on the recording timeline (seconds from the start), instead of the live clock — e.g. to annotate something that happened a few seconds ago. Clamped to >= 0. (The CLI's relative --ago shorthand is CLI-only; compute the absolute second and pass it here.) Note: any assertion is still evaluated NOW, against the live page — if that diverges from the backdated position by >2s, the mark is annotated so the verdict is never misread as pertaining to the backdated moment.
assertTextNoSubstring that must appear in assertSelector's element text. REQUIRES assertSelector — a bare page-body text match is weak evidence and is rejected.
assertSelectorNoCSS selector that must exist on the page at this moment.
Behavior5/5

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

Despite no annotations, the description discloses key behaviors: markers become chapters, two provenances, failure handling (tallied, abort with failMode), backdating limitation, and that assertions are evaluated now even if backdated. Fully transparent.

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?

Description is lengthy but well-structured with clear sections. It front-loads the purpose and then details provenances. Slightly verbose, but every sentence earns its place given complexity.

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?

Given 8 parameters, 1 required, no output schema, and no annotations, the description covers all necessary aspects: provenances, failure modes, backdating, and interaction with other tools. Fully complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but the description adds crucial context: explains the two provenances, that observed requires verdict, that assertText requires assertSelector, and clarifies failMode behavior. Goes well beyond schema.

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?

The description clearly states it drops a live-timestamped narration marker into an active recording session, distinguishing it from siblings like add_chapter. It specifies that markers become transcript chapters, providing a specific verb and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use driver-attested vs clipy-verified, including scenarios like when the agent drives its own browser. Also explains when not to use certain provenances, providing clear context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/manovagyanik1/clipy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server