Skip to main content
Glama

gif_creator

Record browser tab actions into animated GIFs. Start, stop, export, and clear per-tab recordings with visual indicators for clicks and drags.

Instructions

Films a tab as a run of screenshots and encodes them into an animated GIF, with the clicks and drags of the run marked on the frames that show what they did. Four actions, and every one of them needs tabId because a recording belongs to a single tab: start_recording opens the loop and grabs a first frame right away, stop_recording ends the loop after one closing frame and keeps everything captured, export encodes the frames into a .gif on disk, clear throws them out. The loop grabs a frame about every 700 ms and halts itself once 120 are in hand; frames are shrunk to at most 800 px wide, and the delay stored in the GIF follows the cadence that was really measured, not the nominal one. Calling export while the loop still runs stops it first, and the frames outlive the export - clear them when you are done, or the next start_recording carries on the same set. Frames live in server memory only: a tab that closes mid-recording ends the loop with a note in the next reply, and any frame whose size differs from the first (a window resize partway through) is dropped at encode time and counted in the result. Where Chrome pushes the finished GIF through the browser download machinery, this server writes it into the session's download folder itself and gives you back the full path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tabIdYesThe tab to film. Frames are filed under this id, so stop_recording, export and clear only touch the recording that was started for the same tab. tabs_context_mcp lists the ids in this session.
actionYesWhich step to run. start_recording begins capturing this tab, or picks up a set of frames that was stopped earlier; stop_recording closes the loop while keeping the frames; export turns them into a GIF file; clear discards them and frees the memory.
optionsNoOverlay and encoding settings; only export reads them. The five overlay switches - showClickIndicators, showDragPaths, showActionLabels, showProgressBar, showWatermark - are booleans that are all on to begin with, and quality is a number from 1 to 30 that starts at 10. Anything you omit keeps that starting value.
downloadNoKept so a call written for Chrome runs here unchanged, where it routes the GIF through the browser's downloads. This server always writes the file itself and returns its path, so the flag alters nothing; pass it alongside export or leave it off.
filenameNoWhat the exported file should be called; read by export and ignored elsewhere. Left out, the server counts up through recording-1.gif, recording-2.gif and so on, stepping over names already in the folder. Any directory part is stripped, and .gif is appended when the name lacks it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/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. It thoroughly discloses side effects and quirks: frames live in server memory, tab close stops the loop, dropped frames are counted, the server writes the file itself (ignoring the download flag), filename auto-numbering and .gif appending, and the meaning of the quality ranges. These are far beyond typical tool descriptions.

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?

The description is thorough but quite verbose and repetitive. It restates default values multiple times (e.g., quality default, overlay defaults) and uses long, winding sentences. The structure is logical (purpose, actions, details, parameters) but could be tightened significantly without losing information.

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 the tool's complexity (4 actions, 5 parameters, nested options, multiple edge cases), the description is remarkably complete. It covers all actions, parameter effects, default behaviors, memory handling, file output, and even contrasts with Chrome's behavior. No significant aspect is left unexplained.

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?

Although the schema already has 100% description coverage, the prose adds substantial extra meaning: default values for options, the fact that options are only read by export, the filename fallback numbering and directory stripping, and the clarifying note that the download flag is a no-op. This enriches the semantics beyond the 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 opens with a clear statement of purpose: 'Films a tab as a run of screenshots and encodes them into an animated GIF.' It also names the four actions and their roles, and the tool is unique among the siblings (no other tool records or exports GIFs).

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?

The description does not explicitly contrast this tool with alternatives like 'computer' or 'screenshot', but the purpose is so distinct that the intended use case is obvious. It does give guidance on when to use each action (start, stop, export, clear) and mentions that 'export' is the only action that reads options.

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