Skip to main content
Glama
manovagyanik1

@clipy/mcp

by manovagyanik1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

add_marker

Drop a live-timestamped narration marker into the active recording session ('reproduced the bug', 'the fix renders correctly at mobile width').

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 --source 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

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: markers become transcript chapters, failures are annotated as explicit FAILURES rather than fact, failMode 'abort' discards the whole session, pass/unverified claims never abort, and backdated assertions that diverge >2s are annotated to avoid misreading. This is rich, decision-relevant behavioral disclosure.

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-loaded with the core action in the first sentence, then progressively discloses the two lanes and failure semantics. It is dense and somewhat verbose (repeated glyph illustrations, restated 'never both'), but for an 8-parameter tool with zero annotations most sentences earn their place.

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, no annotations, and no output schema, the description is complete enough: it explains the two provenances, required pairings, the abort behavior, backdating semantics, and the glyph rendering a reviewer will see. An agent has what it needs to call this correctly.

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 schema already documents each field. The description still adds meaning by grouping the parameters into the two provenance lanes (one provenance per mark, never both), contextualizing mutual exclusivity and the strength ordering that the per-field schema descriptions state only in isolation.

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?

Specific verb+resource with concrete scope: 'Drop a live-timestamped narration marker into the active recording session', plus the consequence that markers become transcript chapters. This clearly distinguishes add_marker from siblings like add_chapter and add_comment, aided by the 'no audio, stays agent-readable' framing.

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 defines two lanes and when to use each: clipy-verified for asserting against a Clipy-owned page, driver-attested 'when your agent drives its OWN browser/tooling while Clipy records (e.g. via --source screen) or when there is no Clipy-owned page to assert against'. Also states the never-both exclusion and relative strength of each lane.

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