Skip to main content
Glama

loom-mcp

A personal, read-only Loom MCP server for local clients on macOS. Python, uv, the official MCP Python SDK, and HTTPX. Exactly three tools; stdio only.

Verified with MCP Inspector, Claude Code, and Codex CLI: metadata, timestamped transcript, and three readable frames with existing file paths. Focused parsing and setup tests pass. See verification status for evidence and scope.

Install

On your Mac, paste this into Terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/sonmai/loom-mcp/v0.1.3/install.sh)"

The installer checks prerequisites, asks before installing anything missing, installs Loom MCP, and opens a setup wizard:

  1. Choose the local clients you use.

  2. Choose Import from Chrome and follow the permission prompt, or paste a cookie manually.

  3. Once setup saves the cookie in Keychain, restart your clients.

That is all. No clone, Python setup, path editing, or config-file editing is needed. The installer pins a tagged release and its locked dependency versions, so every install of a release gets the same code that was verified. The wizard supports Claude Code, Claude Desktop, Codex CLI, Gemini CLI, Cursor, and VS Code's Default profile. Existing settings are preserved; changed files are backed up. Replacing an existing loom entry requires confirmation.

Import from Chrome (144+): keep a signed-in Loom tab open in your usual Chrome profile. Choose Chrome import in setup. If remote debugging is off, setup offers to open chrome://inspect/#remote-debugging so you can turn it on, then connects again. Setup brings Chrome to the front; click Allow in its connection dialog within 60 seconds. No separate profile or new login is needed if that profile is already signed in. Setup reads the Loom session, disconnects, and saves it in Keychain. You can turn remote debugging off afterward.

Chrome grants broad debugging permission. This importer only lists tab metadata, attaches to a Loom tab, and reads cookies applicable to https://www.loom.com/; it saves only connect.sid. It does not execute page scripts, close your tabs, or read Chrome's cookie database. It supports the standard Chrome Stable user-data location on macOS. If multiple browser contexts have Loom tabs, it asks you to keep one context open instead of guessing an account. Chrome connection documentation.

Manual fallback: sign in to Loom, open your browser's DevTools, select Application > Cookies > https://www.loom.com, and copy the value of connect.sid. Paste it into setup's hidden password prompt. Older Chrome versions, managed browsers that disable debugging, and custom user-data directories can use this route. Failed Chrome imports offer manual entry without replacing Keychain.

The imported cookie is passed on standard input to macOS's security tool, the same tool the server reads it with, so the server can read it without an access prompt. It never appears in command arguments, environment variables, logs, or temporary files. The MCP server continues reading only the Keychain item at runtime.

The installer works on Apple Silicon and Intel Macs. Missing prerequisites are installed through Homebrew, with your consent. Homebrew may request your Mac password or Command Line Tools installation. Downloads need an internet connection. Client apps themselves must already be installed.

Download and read the script before running it:

curl -fsSLo install-loom.sh https://raw.githubusercontent.com/sonmai/loom-mcp/v0.1.3/install.sh
less install-loom.sh
bash install-loom.sh

Already have uv and ffmpeg? Install the package and open setup directly:

uv tool install git+https://github.com/sonmai/loom-mcp.git@v0.1.3
"$(uv tool dir --bin)/loom-mcp" setup

Official uv installation guide. To install without changing Keychain or client settings, use bash install-loom.sh --no-setup. A reviewed local checkout can be installed with bash install.sh --source /absolute/path/to/loom-mcp; its constraints.txt is applied. The manual uv tool install above does not apply the locked versions of indirect dependencies; the installer does.

Related MCP server: Loom Advisor

Run the setup command printed by the installer. If uv is on your shell's PATH, you can also use:

"$(uv tool dir --bin)/loom-mcp" setup

Choose 0 to refresh only the cookie. Otherwise choose the clients to configure. You can keep an existing cookie or import a fresh one from Chrome using the steps above. Expired cookies can also be replaced directly:

security add-generic-password -U -s loom-mcp -a connect.sid -w

Paste the value at the hidden password prompt, never after the command. No server restart is needed for a refreshed cookie. Never paste the cookie into an AI chat.

Troubleshooting

  • No tools after setup: fully restart the client. Confirm its local MCP server named loom is enabled. The wizard reports failures separately for each client.

  • A CLI cannot be found: install that client's command-line launcher and rerun setup, or use the manual configurations below. VS Code's bundled launcher is also detected under /Applications and ~/Applications.

  • A configuration contains comments or cannot be parsed: the wizard leaves it untouched. Claude Code, Codex CLI, Gemini CLI, and VS Code can still be registered through their own CLI after you confirm. For Claude Desktop and Cursor, merge the manual snippet below. Symlinked configuration files are also left for manual configuration.

  • Different VS Code profile: use that profile's MCP: Open User Configuration and the manual snippet. The wizard targets only the Default profile.

  • Custom CLI config directory: if CODEX_HOME, CLAUDE_CONFIG_DIR, or GEMINI_CLI_HOME selects a non-default location, the wizard leaves that client untouched. Use its manual registration command in your usual shell instead.

  • Frames need ffmpeg: rerun the installer, or run brew install ffmpeg. Both Homebrew locations and executables on PATH are supported.

  • Chrome import cannot connect: use Chrome 144+, keep a signed-in Loom tab open, and approve Chrome's connection dialog. If setup reports remote debugging is off, let it open the settings page, turn debugging on, and press Enter to retry. Setup never turns debugging on itself. Manual entry remains available.

  • Cookie missing or access denied: rerun setup and choose cookie-only mode. Allow the local process to access the Keychain item if macOS asks.

  • Keychain prompts on every tool call after a Chrome import in v0.1.1 or earlier: those versions created the item in a way security cannot read silently. Delete it with security delete-generic-password -s loom-mcp -a connect.sid, then rerun setup and import again.

Manual client configuration

For command-line clients, these commands automatically find the installed executable. For JSON configurations, replace /absolute/path/to/loom-mcp with the path printed by:

printf '%s/loom-mcp\n' "$(uv tool dir --bin)"

Merge entries into existing configurations rather than replacing other servers. Credentials stay in Keychain.

Claude Code

Official MCP documentation.

claude mcp add --transport stdio --scope user loom -- "$(uv tool dir --bin)/loom-mcp"

Codex CLI

Official MCP registration source.

codex mcp add loom -- "$(uv tool dir --bin)/loom-mcp"

Claude Desktop

Merge into ~/Library/Application Support/Claude/claude_desktop_config.json (Settings > Developer > Edit Config). Official local-server guide.

{
  "mcpServers": {
    "loom": { "command": "/absolute/path/to/loom-mcp" }
  }
}

Gemini CLI

Merge into ~/.gemini/settings.json. Official MCP documentation and configuration locations.

{
  "mcpServers": {
    "loom": { "command": "/absolute/path/to/loom-mcp" }
  }
}

Cursor

Merge into ~/.cursor/mcp.json. Official MCP documentation.

{
  "mcpServers": {
    "loom": { "command": "/absolute/path/to/loom-mcp" }
  }
}

VS Code

Run MCP: Open User Configuration and merge into that mcp.json. Official configuration reference.

{
  "servers": {
    "loom": { "type": "stdio", "command": "/absolute/path/to/loom-mcp" }
  }
}

Formats were checked against the linked documentation on 2026-10-29. Existing installations using uv run --directory ... loom-mcp continue to work; there is no need to change them. Only Claude Code and Codex CLI have been runtime-tested, using that local-checkout launch command.

Update

Rerun the one-command installer from the Install section. It names the latest release, installs it with locked dependencies, and checks your setup.

Restart the client to use the updated server. The Keychain cookie and media cache are retained.

Tools

Tool

Arguments

Result

get_video

video: HTTPS Loom share URL or 32-character hexadecimal ID

JSON text with id, name, owner, duration_seconds, created_at, description; unavailable optional values are null

get_transcript

video

JSON text with video_id and segments, each containing timestamp_seconds, text, and speaker (null if unavailable)

get_frames

video, timestamps: 1–10 numbers or strings

For each input position, a text block containing timestamp_seconds and absolute path, followed by PNG MCP image content

For example, timestamps: ["0:39", "1:14", "1:39"] is equivalent to [39, 74, 99]. Decimal seconds are accepted. Strings use seconds or M:SS; hours can be expressed as total minutes. Negative values, non-finite values, and positions at or beyond the duration are rejected. The exact endpoint has no frame. Input order and duplicates are preserved.

Frames are scaled to 1280 pixels wide with the aspect ratio preserved and saved under ~/Library/Caches/loom-mcp/<video_id>/frames/. Both image content and an absolute path are returned so a client that drops image content can still read the PNG locally. The MP4 is cached at ~/Library/Caches/loom-mcp/<video_id>.mp4. Separate processes share a per-video file lock; downloads are installed atomically. Frame calls re-check video metadata and duration, even when the MP4 is cached.

The cache is not automatically refreshed when a video is edited. Delete the affected MP4 manually to force a fresh download. If ffmpeg cannot read a cached MP4, it is downloaded again once. The cache directory is private to your account. A video's MP4 and frames are deleted after 30 days without a frame request, even if its cookie has expired. There is no other cache-management tool.

Development and verification

For a local checkout, the original entry point remains available:

uv run --directory /absolute/path/to/loom-mcp loom-mcp

The project uses Python 3.11+, the official MCP SDK, and HTTPX. uv_build is the build backend. No extra runtime dependency is needed for installation.

To inspect the standalone installation:

npx @modelcontextprotocol/inspector "$(uv tool dir --bin)/loom-mcp"

Connect using stdio and confirm tools/list contains exactly get_video, get_transcript, and get_frames, with read-only annotations. Call each with video set to a share URL you can access:

  1. get_video: confirm the name and duration match the video.

  2. get_transcript: compare the first segment with the video's opening words.

  3. get_frames: choose timestamps before the end of the video; inspect each returned image and confirm its absolute PNG path exists.

For development, run the focused standard-library tests from a local checkout:

uv run --directory /absolute/path/to/loom-mcp python -m unittest discover -s tests

To cut a release, set the same version in pyproject.toml and release in install.sh (a test enforces this), regenerate the constraints, update the v… URLs in this README, and push a matching tag:

uv export --frozen --no-hashes --no-dev --no-emit-project -o constraints.txt
git tag v0.1.3 && git push origin v0.1.3

uv tool install ignores uv.lock, so constraints.txt is how the installer applies the locked versions. The installer downloads it from the release tag.

Limits and attribution

Authentication reads only the loom-mcp / connect.sid Keychain item at runtime. Errors never include cookie values or raw HTTP/subprocess diagnostics. Logs go to stderr; stdout is the MCP channel.

macOS only, because authentication uses Keychain. Stdio only. Remote HTTP clients are out of scope: a remotely hosted server would need to hold the browser cookie. The server has no HTTP transport and no client-specific runtime behavior.

This uses an undocumented internal API that can break. A cookie grants whatever access the browser session has; this server exposes only fixed read queries. It cannot bypass sharing restrictions, supply video passwords, generate transcripts, or regenerate MP4 exports. Missing MP4 exports cause a clear error; there is no DASH fallback in this small implementation. Only local cache files are written. No Loom data is modified.

The GraphQL queries are adapted from karbassi/mcp-loom@9d5f0ce5bfad960541ae11a3e525640d5acc8081 (MIT). See THIRD_PARTY_NOTICES.md for the full notice, and docs/upstream.md for exact source queries and adaptations. The upstream package is not installed or executed.

License

MIT. Adapted upstream queries keep their own MIT notice in THIRD_PARTY_NOTICES.md.

Available Tools

3 tools
get_framesA
Read-only

Read still frames at 1–10 timestamps, in input order, scaled to 1280 pixels wide.

Accepts an HTTPS Loom share URL or video ID. For every timestamp, returns a text block with seconds and an absolute PNG path, followed by its MCP image content. Files are saved under ~/Library/Caches/loom-mcp/<video_id>/frames/. Downloads and reuses a local MP4 cache. Requires an available MP4 export. Does not modify Loom.

NameRequiredDescriptionDefault
videoYesHTTPS Loom share URL or 32-character hexadecimal video ID.
timestampsYes1–10 positions: seconds (39, 74.5, or '39') or M:SS ('0:39', '1:14'). Each must be finite, non-negative, and less than the video duration.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already establish readOnly, openWorld, and non-destructive behavior, and the description adds substantial context: input-order processing, 1280px scaling, return structure, cache location, local MP4 reuse, and MP4 export prerequisite. It also confirms it does not modify Loom.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and constraints are front-loaded, then followed by return format and caching details. Every sentence carries operational value for invoking the tool correctly.

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?

With no output schema, the description fully explains the return shape, saved file paths, and MCP image content. It also covers the key prerequisite and cache behavior, leaving no major ambiguity for a two-parameter tool.

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. The description still adds useful semantics beyond the schema by noting that timestamps are processed in input order and frames are scaled to 1280 pixels wide.

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?

States a specific verb and resource: read still frames at 1–10 timestamps. The action is clearly distinct from sibling tools get_video and get_transcript even without naming them explicitly.

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?

Usage is implied by the frame-extraction purpose, accepted video input formats, and the requirement for an available MP4 export. However, it does not explicitly say when to choose this over get_video or get_transcript.

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

get_transcriptA
Read-only

Read a Loom transcript as JSON text with timestamped segments.

Accepts an HTTPS share URL or video ID. Each segment contains timestamp_seconds, text, and speaker (null when unavailable). Reports an error if no transcript is available. Does not generate or modify transcripts.

NameRequiredDescriptionDefault
videoYesHTTPS Loom share URL or 32-character hexadecimal video ID.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, and the description adds substantial context on top: the segment fields returned, that speaker is null when unavailable, and that a missing transcript yields an error rather than empty data. It omits auth/permission requirements and any rate-limit behavior, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences, front-loaded with the action and return format, then the input forms, then the failure mode and exclusion. Every sentence carries information an agent would otherwise have to guess.

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 one-parameter read tool with no output schema, the description fully carries the burden: it describes the return structure, the null-field convention, the error case, and the non-generative limitation. Nothing needed to call it correctly is missing.

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

Parameters3/5

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

The single parameter has 100% schema description coverage, so the schema already documents the two accepted forms. The description restates 'Accepts an HTTPS share URL or video ID' without adding format, validation, or conversion details beyond what the schema provides, so the baseline 3 applies.

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 and resource ('Read a Loom transcript') plus the return shape ('JSON text with timestamped segments'), so the agent knows exactly what it gets. It never names the sibling tools get_video or get_frames, so differentiation is left implicit.

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?

It sets a clear scope boundary with 'Does not generate or modify transcripts' and discloses the failure mode when no transcript exists, which implies when the tool is applicable. However, it gives no guidance on when to prefer this over get_video or get_frames, so routing must be inferred from the names.

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

get_videoA
Read-only

Read a Loom video's name, owner, duration in seconds, creation date, and description.

Accepts an HTTPS share URL or video ID. Returns JSON text; unavailable optional metadata is null. Does not modify the video.

NameRequiredDescriptionDefault
videoYesHTTPS Loom share URL or 32-character hexadecimal video ID.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description doesn't need to justify them. It still adds useful behavior: the return is JSON text and absent optional metadata is returned as null, which tells the agent how to interpret partial results. The closing 'Does not modify the video' largely restates readOnlyHint.

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?

Three short sentences, front-loaded with what is returned, then input forms, then behavioral notes. Only the final 'Does not modify the video' clause is wasted since annotations already declare it.

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?

With one parameter, no output schema, and full schema coverage, the description supplies the missing piece an agent needs: which fields are returned and that unavailable optional metadata appears as null. Nothing required to call it correctly is absent.

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

Parameters3/5

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

Schema coverage is 100% and the parameter description already spells out 'HTTPS Loom share URL or 32-character hexadecimal video ID'. The description restates the accepted input forms but drops the 32-character hexadecimal detail, so it adds nothing beyond the schema. Baseline 3 applies.

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 (Read) and resource (a Loom video) and enumerates exactly which metadata fields come back (name, owner, duration, creation date, description). That field list implicitly separates it from get_transcript and get_frames, though neither sibling is named explicitly.

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?

The description makes clear this is a metadata lookup and notes it takes a share URL or video ID, so correct usage is inferable. It never states when to prefer it over get_transcript or get_frames, nor any conditions where it should not be used.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.3
    • First observedget_frames
    • First observedget_transcript
    • First observedget_video

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

The three tools map to clearly distinct outputs: video metadata, transcript text, and extracted still frames. An agent can easily choose based on the desired artifact, and the descriptions reinforce the boundaries.

Naming Consistency5/5

All tools follow the same get_<resource> pattern, and the nouns are concrete and predictable. There is no mixing of casing or verb conventions.

Tool Count5/5

Three tools is a well-scoped surface for a read-only Loom integration focused on metadata, transcripts, and frames. Each tool serves a distinct retrieval purpose without unnecessary bulk.

Completeness4/5

The set covers the core read-only extraction workflows implied by the server, including metadata, transcript, and visual frames. It lacks discovery or listing operations, but since the tools accept share URLs or IDs, this is a minor gap rather than a blocking one.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers