Which integrations are available for this server?

Provides tools for managing Loom screen recordings, including listing, retrieving, editing (trimming/extracting clips), and merging videos.

How do I use Loom Advisor?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Loom Advisor list my recent Loom videos" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Loom Advisor

by m2ai-mcp-servers

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Loom Advisor

MCP server for Loom video management. Provides tools to list, retrieve, edit, and merge Loom screen recordings.

Features

list_recorded_videos - Retrieve a list of recorded videos with pagination and folder filtering
get_video - Get detailed information about a specific video
edit_video - Edit videos by trimming or extracting clips
merge_videos - Combine multiple videos into one

Related MCP server: Loom Local MCP Server

Installation

pip install m2ai-mcp-loom-advisor

Configuration

Required environment variables:

Variable	Description
`LOOM_ACCESS_TOKEN`	OAuth2 access token for Loom API

Optional environment variables:

Variable	Description	Default
`LOOM_BASE_URL`	Loom API base URL	`https://api.loom.com/v1`

Getting an Access Token

Loom uses OAuth2 for authentication. To obtain an access token:

Register your application in the Loom Developer Portal
Implement the OAuth2 authorization flow
Use the returned access token in your configuration

Note: Loom's public API access may be limited. Enterprise users may have additional API capabilities. Contact Loom for API access details.

Usage with Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "loom": {
      "command": "loom-advisor",
      "env": {
        "LOOM_ACCESS_TOKEN": "your-access-token"
      }
    }
  }
}

Or run directly with Python:

{
  "mcpServers": {
    "loom": {
      "command": "python",
      "args": ["-m", "loom_mcp.server"],
      "env": {
        "LOOM_ACCESS_TOKEN": "your-access-token"
      }
    }
  }
}

Tools

list_recorded_videos

Retrieve a list of recorded videos from Loom.

Parameters:

limit (optional): Maximum number of videos to return (1-100, default 50)
offset (optional): Pagination offset (default 0)
folder_id (optional): Filter videos by folder ID

Example:

{
  "limit": 10,
  "offset": 0,
  "folder_id": "folder-abc"
}

get_video

Retrieve detailed information about a specific video.

Parameters:

video_id (required): Unique identifier for the video

Example:

{
  "video_id": "abc123"
}

edit_video

Edit a video by adding clips or trimming sections.

Parameters:

video_id (required): Unique identifier for the video
editing_details (required): Object containing edit instructions
- trim_start: Start time in seconds to trim from beginning
- trim_end: End time in seconds where video should end
- clips: List of clip objects with start and end times
- title: Optional new title for the edited video
- description: Optional new description

Example:

{
  "video_id": "abc123",
  "editing_details": {
    "trim_start": 5,
    "trim_end": 120,
    "title": "Edited Demo"
  }
}

merge_videos

Combine multiple videos into one merged video.

Parameters:

video_ids (required): List of video IDs to merge (minimum 2, in order)
title (optional): Title for the merged video

Example:

{
  "video_ids": ["video-1", "video-2", "video-3"],
  "title": "Combined Demo"
}

Development

Running Tests

# Activate virtual environment
source venv/bin/activate

# Run tests
pytest

# Run with coverage
pytest --cov=loom_mcp --cov-report=term-missing

Code Quality

# Format and lint
ruff check src tests
ruff format src tests

# Type checking
mypy src

Project Structure

loom-mcp/
├── src/
│   └── loom_mcp/
│       ├── __init__.py
│       ├── server.py          # MCP server entry point
│       ├── clients/
│       │   ├── __init__.py
│       │   └── loom.py        # Loom API client
│       └── tools/
│           ├── __init__.py
│           ├── list_recorded_videos.py
│           ├── get_video.py
│           ├── edit_video.py
│           └── merge_videos.py
├── tests/
│   ├── __init__.py
│   ├── conftest.py
│   ├── test_loom_client.py
│   ├── test_tools.py
│   └── test_server.py
├── pyproject.toml
├── README.md
└── .env.example

License

MIT

Generated by GRIMLOCK MCP Factory

Available Tools

4 tools

edit_videoB

Edit a video by adding clips or trimming sections. Supports trimming start/end, extracting clips, and updating metadata like title and description.

ParametersJSON Schema

Name	Required	Description	Default
`video_id`	Yes	Unique identifier for the video
`editing_details`	Yes	Details for editing the video. Supported options: - trim_start: Start time in seconds to trim from beginning - trim_end: End time in seconds where video should end - clips: List of clip objects with 'start' and 'end' times in seconds - title: Optional new title for the edited video - description: Optional new description for the edited video

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It mentions supported editing operations but fails to disclose critical behavioral traits such as whether edits are destructive (overwrite original) or create a new version, permissions required, or impact on existing data. The description is vague about side effects.

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 description is extremely concise: two sentences that cover the core functionality and list supported options. No wasted words, front-loaded with the main verb 'Edit a video'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (2 params, nested object, no output schema, no annotations), the description is minimal. It covers the main operations but misses important context like return value, error handling, or prerequisites (e.g., video must exist). Adequate for a simple tool but incomplete for production use.

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?

Input schema coverage is 100% with detailed property descriptions. The description summarizes the editing options but adds no additional meaning beyond what is already in the schema. For a high-coverage schema, baseline is 3, and the description does not exceed that.

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 clearly states it edits a video by adding clips or trimming sections, and lists specific operations like trimming start/end, extracting clips, and updating metadata. While it differentiates from siblings (get_video, list_recorded_videos) by being an edit operation, it does not explicitly distinguish from merge_videos, but the verb 'edit' implies single video modification.

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 provides a clear purpose but lacks explicit guidance on when to use this tool versus alternatives like merge_videos. It implies usage for editing a single video, but does not state when not to use it or mention prerequisites. The context hints from sibling names partially compensate, but no direct comparison.

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

get_videoA

Retrieve a specific video by ID. Returns full video details including title, description, duration, embed URL, share link, and transcript availability.

ParametersJSON Schema

Name	Required	Description	Default
`video_id`	Yes	Unique identifier for the video

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns details (implying a read operation), but it does not mention potential side effects, authentication requirements, rate limits, or failure behavior (e.g., if the video ID is invalid or missing). This is insufficient for a tool with no annotations.

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?

The description is a single sentence that efficiently conveys the core action and output. It could be slightly more structured (e.g., listing return fields explicitly), but for this simple case it is appropriately sized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 parameter, 100% schema coverage, no output schema), the description is fairly complete. It lists key return fields (title, description, duration, etc.), though it could mention error handling or prerequisites. Overall, sufficient for the agent's decision-making.

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 schema description for video_id is 'Unique identifier for the video', which is clear. The tool description adds that the tool returns full details but does not add new semantics beyond the schema. Since schema coverage is 100%, the baseline score of 3 is appropriate.

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 uses the specific verb 'Retrieve' and identifies the resource as 'a specific video by ID'. It clearly distinguishes from sibling tools like edit_video (modify) and merge_videos (combine), leaving no ambiguity about its function.

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 implies usage when a video's full details are needed by ID, but it does not explicitly state when to use this tool versus alternatives like list_recorded_videos (to browse) or edit_video (to modify). The context from sibling names provides indirect guidance, but the description itself lacks direct usage instructions.

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

list_recorded_videosA

Retrieve a list of recorded videos from Loom. Returns video metadata including IDs, titles, thumbnails, and creation dates. Supports pagination and folder filtering.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of videos to return (1-100, default 50)
`offset`	No	Pagination offset (default 0)
`folder_id`	No	Optional folder ID to filter videos by folder

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions return metadata and features but lacks details on authentication, ordering, or potential side effects.

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?

Two efficient sentences. The first sentence front-loads the purpose, the second adds return fields and features. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers returned metadata and features for a list tool. Missing details like default ordering or error cases, but acceptable given simplicity.

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%, so baseline is 3. The description echoes pagination and folder filtering, but parameter descriptions already provide full semantics.

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 the tool retrieves a list of recorded videos from Loom, specifying the action and resource. It distinguishes itself from siblings (edit_video, get_video, merge_videos) as the listing tool.

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 implies usage through listing and filtering capabilities but does not explicitly state when to use this tool over alternatives like get_video for single video retrieval.

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

merge_videosA

Combine multiple videos into one merged video. Provide at least 2 video IDs in the desired merge order. Optionally specify a title for the merged result.

ParametersJSON Schema

Name	Required	Description	Default
`video_ids`	Yes	List of Video IDs to merge (minimum 2). Videos will be merged in the order provided.
`title`	No	Optional title for the merged video

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It mentions combining videos but omits whether original files are preserved, return format, or side effects like file deletion. This is insufficient for a mutation tool.

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?

Two sentences, front-loaded with core operation, no extraneous text. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and simple parameters, the description covers basic usage. However, it lacks return value description and fails to mention whether originals are unaffected, leaving context gaps.

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?

Input schema already describes both parameters with 100% coverage. The description adds emphasis on ordering and minimum count, which is mildly helpful but not significantly 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 'Combine multiple videos into one merged video,' with a specific verb and resource. It distinguishes from sibling tools like edit_video and get_video, which perform different actions.

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?

Description explicitly requires at least 2 video IDs and notes order matters, providing concrete usage instructions. It does not discuss when not to use, but siblings are distinct enough to avoid confusion.

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.

4 tool updatesv1.0.0May 26, 2026
- First observededit_video
- First observedget_video
- First observedlist_recorded_videos
- First observedmerge_videos

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-26 07:30 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: editing, retrieving by ID, listing, and merging videos. There is no overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (edit_video, get_video, list_recorded_videos, merge_videos) with predictable structure.

Tool Count4/5

4 tools is a reasonable number for a video management server, covering core operations. It is slightly on the smaller side but not insufficient.

Completeness3/5

The tool set covers listing, retrieval, editing (including metadata), and merging, but lacks a delete tool, which is a notable gap for full lifecycle management.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ShotstackOAuth
io.shotstack
Generate, edit, and render videos via the Shotstack video editing API.
Multimedia Processing Image & Video Processing
1
TeleprompterOAuth
com.teleprompter
Read and write your Teleprompter.com scripts and folders: list, create, update, and organize.
Entertainment & Media Content Management Systems
2
apivideo A
io.usefulapi
Manage videos and live streams, inspect captions, players and webhooks, and read play analytics.
Entertainment & Media Multimedia Processing
152
note1.ai AOAuth
ai.note1
Search meetings, export summaries and transcripts, and manage recordings from any AI tool.
Search Note Taking Communication
1

Related MCP Servers

Shortcut MCP Server
Project Management Developer Tools
currentspace
A
license
Not graded
quality
D
maintenance
Provides comprehensive tools for interacting with the Shortcut API, enabling developers to manage stories, comments, projects, and analyze Loom videos for debugging insights.
Updated a year ago (2025-07-08 01:22 UTC)
7
ISC
Loom Local MCP Server
Multimedia Processing Testing & QA Tools Developer Tools
Slaycaster
F
license
Not graded
quality
D
maintenance
Extracts and analyzes key frames from Loom videos or local video files for debugging purposes. Automatically detects scene changes and provides visual context for troubleshooting issues.
Updated 3 months ago (2026-06-02 08:10 UTC)
4
-
Loom Transcript MCP
Web Scraping Multimedia Processing Content Management Systems
bStyler
F
license
B
quality
Not graded
maintenance
Enables users to fetch transcripts and comments from public Loom video URLs. It provides tools to retrieve video text data and discussion threads directly through the Model Context Protocol.
Updated 9 months ago (2025-12-15 20:15 UTC)
2
-
loom-mcp
Communication Content Management Systems
karbassi
A
license
A
quality
D
maintenance
MCP server that exposes 59 tools for Loom's internal GraphQL API, enabling listing, searching, and managing Loom videos, transcripts, comments, tasks, and more.
Updated 6 months ago (2026-03-18 14:40 UTC)
60
8
MIT