Skip to main content
Glama

Annotate

media_annotate
Destructive

Writes notes, comments and marked areas into local PDFs, video, audio and images so annotations persist across sessions and stay visible to humans. Creates real PDF objects plus sidecar JSON/VTT files.

Instructions

Write annotations (notes, comments, sticky notes, marked areas) into a local media file so they survive across sessions and are visible to humans in the file itself: real PDF annotation objects for a PDF, a sidecar VTT for video/audio, and a sidecar JSON for every supported media type. (写入批注 / 注释 / 评论 / 标注:PDF 原地写真正的批注对象;视频、音频写同名 .mmgrep.annotation.vtt;所有类型都写 .mmgrep.annotation.json 侧车。 中文触发词:批注、注释、评论、标注、annotate、comment、note。)

The sidecar ".mmgrep.annotation.json" is the single source of truth. The first write (no sidecar yet) imports every note-like annotation of a PDF — Text, FreeText, Square, Circle, Line, Polygon, PolyLine, Highlight, Underline, Squiggly, StrikeOut, Stamp, Caret and Ink, in page order — as n1…nN, including its raw geometry and original author, then applies this call. Link annotations, form widgets and popups are never imported or touched. Entries are anchored per media type:

  • PDF: page (1-based PHYSICAL page) + type ("text" = sticky note, "square" = rectangle area; "square" also needs rect {x,y,width,height} as fractions 0..1 of the page). Other annotation types cannot be created in this version, but imported ones are kept verbatim (including raw geometry) and can be updated (note) or removed.

  • video/audio: start (seconds, < duration) and optional end (default start + 5 s, clipped to the end of the media). No page, no rect, no type.

  • image: rect only (fractions of the image); no page, start/end or type.

  • every entry: note (plain text, 1..4000 characters, newlines allowed) and, for PDF, type.

Ids are n1, n2, …; new ids are max+1 and are never reused by this call; update keeps the id. One call can mix add / remove / update; they are applied remove → update → add, all-or-nothing: if anything is invalid, nothing is written and every problem is listed at once (unknown id, bad field, page/time out of range, duplicate ids, malformed entry, …).

The author is resolved once per call: the "author" argument, else the MCP client's name, else "MultiMediaGrep". The model name is never used. Imported annotations keep their original author; update never changes it.

WARNING — this tool modifies files:

  • A PDF is modified IN PLACE: annotation objects are written into the PDF file itself, no copy is made (the page content is not rewritten). Video and audio files are never modified — only the VTT is written.

  • Files are written NEXT TO the source: a .mmgrep. sidecar for every media type, plus *.mmgrep.annotation.vtt for video/audio. They are not written into the cache directory.

  • When a sidecar already exists, external edits to the file's own annotations are OVERWRITTEN on the next write. To change an annotation, use update; the sidecar wins over the file.

  • Protect your originals with git (or a backup) before calling this tool.

The result lists every written annotation in the same shape the read side uses ("n1 (p.12): note", "n1 (00:12:34–00:12:39): note"), plus the sidecar path, the embed target, and every check result. (批注 / 注释 / 评论 / 标注 / annotate / comment / note)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "media_annotate"
  }
}

Input Schema

NameRequiredDescriptionDefault
addNoAnnotations to add. Each gets a new id (max+1); do not pass "id". (新增批注:note + type/page(PDF)或 start/end(视频/音频)或 rect(图片))
pathYesAbsolute path to a LOCAL file: video, audio recording, or document. URLs and relative paths are rejected — this server never downloads anything. (本地文件绝对路径)
authorNoWho is writing these annotations (stored in the sidecar and, for PDF, in the annotation). Defaults to the MCP client's name, then "MultiMediaGrep". Imported annotations keep their original author; update never changes it. (批注作者)
removeNoAnnotation ids to remove, e.g. ["n2"]. Unknown or duplicate ids are errors and nothing is written. (删除批注:n1、n2 …)
updateNoAnnotations to update: pass "id" plus at least one of note / type / page / rect / start / end. The id and the author never change. (更新批注:保留 id,只改内容 / 位置)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations, which already declare destructiveHint=true and readOnlyHint=false. The WARNING block discloses that PDFs are modified in place with no copy, that video/audio files are left untouched while a VTT sidecar is written, that sidecars sit next to the source rather than in a cache directory, and that pre-existing external annotation edits are overwritten on the next write. It even advises protecting originals with git or a backup, and explains id allocation (max+1, never reused) and author resolution order.

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?

Front-loaded and organized into clearly labeled sections (anchoring per media type, ids, error semantics, author, WARNING, result shape), which makes a long description navigable. But it is oversized for a five-parameter tool, repeats schema-level constraints verbatim, and bookends the text with the same bilingual keyword list twice — content that does not earn its space in an agent-facing definition.

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 destructive, non-idempotent mutation tool with no output schema, the description covers everything an agent needs: mutation scope and reversibility, sidecar locations, overwrite semantics, import behavior, error atomicity, author resolution, and the shape of the returned listing. There is no material gap left unaddressed.

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 description coverage is already 100%, so baseline is 3; the description earns above that by adding cross-parameter semantics the schema cannot express — the per-media-type field matrix, the default end of start + 5 s clipped to media duration, 'page' meaning 1-based physical pages consistent with media_overview, imported annotations keeping their original author, and the all-or-nothing validation ordering. It does duplicate a fair amount (note length 1..4000) that the schema already states.

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 opens with a precise verb+resource+side-effect: writing annotations into a local media file so they persist and are visible to humans, with per-format mechanics (real PDF annotation objects, sidecar VTT, sidecar JSON). That is unambiguous. What it does not do is distinguish the tool from the closest sibling, media_bookmark, which an agent could plausibly reach for when it wants to mark a spot in media.

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?

Usage is spelled out thoroughly at the mechanical level: which fields apply per media type (PDF page/type/rect, video start/end, image rect-only), what happens on first write (import of existing PDF annotations), and that one call may mix add/remove/update applied remove→update→add, all-or-nothing. There is still no explicit 'use this tool rather than X when…' routing against media_bookmark or media_overview.

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