Allows placing b-roll clips directly onto a DaVinci Resolve timeline.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@broll-studio-mcp Find 3 vertical clips of a sunset and add to Resolve timeline."
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.
Lets Claude Code turn a topic into real b-roll on an editor timeline: search → download → judge → place on a timeline. Talks to the hosted B-Roll Studio API; needs only a personal API key.
Tool | What it does |
| Real, relevant assets (images, stock video, YouTube, tweets, articles), each with a downloadable file. Supports mix weights + aspect ratio. |
| Saves an asset to a local file. |
| Direct to timeline (DaVinci Resolve): appends clips to your open timeline live. |
| Direct to timeline (Premiere): writes a |
| Universal fallback: writes FCPXML + EDL + manifest for any editor. |
Related MCP server: resolve-mcp
Needs Node 18+ and the Claude Code CLI. Get a key from B-Roll Studio → Settings → API keys, then:
npm install -g github:Gaffattack54/broll-studio-mcp
claude mcp add broll-studio broll-studio-mcp -s user \
-e BROLL_API_KEY=brs_live_your_key \
-e BROLL_API_BASE=https://broll-studio-ten.vercel.appVerify: claude mcp list → broll-studio: ✓ Connected. The server is now
available in every Claude Code project on that machine.
Use one key per machine so you can revoke a single machine in Settings without affecting the others.
Open Claude Code in any project and ask:
Find 6 vertical b-roll clips and images of the New York City skyline, download the good ones to
D:/edit/nyc, and build a timeline there.
Only images and stock video download as the actual media. Tweets and
articles render to image cards; YouTube returns its thumbnail still (with the
watch link in page_url).
place_in_resolve needs Resolve running with Preferences → System → General →
External scripting using = Local, and Python 3 installed.
Generate a Premiere Pro script (premiere_insert.jsx) that imports the chosen clips and appends them to your ACTIVE sequence. Run it in Premiere via File > Scripts (or the ExtendScript runner) with a project + sequence open. This is the direct-to-timeline path for Premiere.
| Name | Required | Description | Default |
|---|---|---|---|
| clips | Yes | Clips to append, in order. | |
| out_dir | Yes | Absolute directory to write the .jsx into. Created if missing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (generates a script that appends clips to the active sequence) and that the script file is written to out_dir. However, it does not mention potential error conditions (e.g., if no sequence is open) or side effects beyond timeline modification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three efficient sentences: purpose, usage, and identity. Every sentence adds unique value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description covers all essential aspects: what it does, how to use it, prerequisites, and the output file. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by explaining that clips are 'chosen' and appended in order, and that out_dir is created if missing. It also clarifies the default duration for stills (5 seconds).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('generate') and resource ('Premiere Pro script'), and clearly states the action ('imports the chosen clips and appends them to your ACTIVE sequence'). It distinguishes from siblings by calling it 'the direct-to-timeline path for Premiere'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use the tool ('Run it in Premiere via File > Scripts... with a project + sequence open') and implicitly contrasts with sibling tools (e.g., place_in_resolve). It does not explicitly state when not to use it, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write an editor timeline from chosen, already-downloaded clips. Emits timeline.fcpxml (Final Cut / DaVinci Resolve / Premiere), timeline.edl (universal fallback), and manifest.json into the output directory. Clips are laid end-to-end as a rough assembly.
| Name | Required | Description | Default |
|---|---|---|---|
| clips | Yes | Ordered clips to place on the timeline. | |
| title | No | Timeline/project name. | |
| out_dir | Yes | Absolute directory to write the timeline files into. Created if missing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output files, default durations, and that out_dir is created if missing. No annotations provided, so description carries burden; lacks details on permissions, error handling, or reversal, but adequate for a non-destructive assembly tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: purpose/output, specific file types, assembly behavior. No wasted words, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers outputs, defaults, directory creation. No output schema, so description explains return value implicitly. Could mention error behavior, but overall sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds context (e.g., 'already-downloaded', defaults for still/video) but does not substantially extend beyond schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it writes a timeline from downloaded clips, specifies output formats (FCPXML, EDL, manifest), and distinguishes from siblings like build_premiere_script (script output) and place_in_resolve (direct placement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when clips are already downloaded and a timeline is needed, but does not explicitly state when to avoid this tool or mention alternatives like build_premiere_script or place_in_resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a single asset URL (from search_broll's download_url) to a local file so it can be inspected and used on a timeline. Every asset type returns something downloadable: images, stock video, tweet/article cards, and YouTube thumbnail stills. For YouTube, page_url is the link to the actual moving clip.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | Yes | Absolute directory to save into. Created if missing. | |
| url | Yes | The asset's download_url. | |
| filename | No | Optional filename. Defaults to a name derived from the URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool works for all asset types, creates directories if missing, and notes the YouTube URL nuance. However, it does not mention overwrite behavior, error handling, or return values. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences. The first states the primary purpose, and the second adds a critical nuance about YouTube. No wasted words; front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values (e.g., saved file path, success status). It does not. It also omits error cases or prerequisites beyond the URL source. While it covers core functionality well, the lack of return value documentation is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context that 'url' is from search_broll and that 'dir' is absolute and created if missing, but this does not significantly exceed what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a single asset URL to a local file for timeline use, and specifies it comes from search_broll's download_url. It distinguishes from siblings like build_premiere_script, build_timeline, and place_in_resolve, which handle other stages of asset processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context that all asset types are downloadable and adds a specific note about YouTube (page_url for moving clips). It implies usage after search_broll but lacks explicit when-not-to-use or alternative tool guidance. Clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert already-downloaded clips DIRECTLY onto the open DaVinci Resolve timeline — imports them into the media pool and appends to the current timeline (creating one if none is open). Requires Resolve to be running with external scripting enabled (Preferences > System > General > External scripting using = Local).
| Name | Required | Description | Default |
|---|---|---|---|
| clips | Yes | Downloaded clips to append, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the required state of Resolve, the import/appending behavior, and timeline creation. It does not mention error handling or limits, but the core behavioral traits are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence delivers the core purpose, and the second adds a crucial prerequisite. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the essential actions and prerequisites. It could mention error handling or fallback behavior, but is sufficiently complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'clips' well-documented in the schema. The description adds emphasis on 'already-downloaded' and 'DIRECTLY', but does not significantly enhance understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Insert already-downloaded clips DIRECTLY onto the open DaVinci Resolve timeline'), the resource (clips), and the additional steps (imports into media pool, appends to timeline). It effectively distinguishes this tool from siblings like build_premiere_script and build_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a key prerequisite (Resolve running with external scripting enabled) and implies when to use (after downloading clips). It lacks explicit 'when not to use' or alternatives, but the context of siblings and the specific phrasing provide adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search B-Roll Studio for real, embeddable b-roll for a topic or moment. Returns assets with direct, downloadable URLs (images: full_url, stock video: video_url). Use the weights to bias the mix (0=off..3=heavy) and aspect to set the frame shape.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What the b-roll should depict, e.g. 'New York City skyline at dusk'. | |
| aspect | No | Frame shape for images + stock video. 'landscape'=16:9, 'portrait'=9:16, 'square'=1:1. | |
| weights | No | Per-type emphasis 0..3. Omit for an even mix. Set a type to 0 to exclude it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It transparently states 'Returns assets with direct, downloadable URLs (images: full_url, stock video: video_url).' This discloses the output format and indicates it's a read-only operation. No destructive behavior is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences, front-loading the core purpose and then providing usage hints. Every sentence is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters (one required) and no output schema, the description explains the return value (URLs) and hints at weighting. It is complete enough for an agent to use correctly. Minor gap: no mention of pagination or result limits, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage (e.g., 'query' description, 'aspect' enum descriptions, 'weights' nested description). The description adds value by summarizing how to use weights and aspect, and by specifying the return URL types, which is not in the schema. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search B-Roll Studio for real, embeddable b-roll for a topic or moment.' It specifies the resource (B-Roll Studio) and the action (search), and differentiates from siblings which are about building scripts, timelines, downloading, or placing assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use the weights to bias the mix (0=off..3=heavy) and aspect to set the frame shape.' It does not explicitly state when not to use or mention alternatives, but the context is clear for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0build_premiere_scriptbuild_timelinedownload_assetplace_in_resolvesearch_brollEach tool has a clearly distinct purpose: search_broll finds assets, download_asset retrieves them, and the three timeline tools target different editing environments (Premiere script, universal timeline files, Davinci Resolve direct insertion). No overlap.
All tool names use snake_case with a verb_noun pattern (build_premiere_script, build_timeline, download_asset, place_in_resolve, search_broll). Naming is uniform and predictable.
Five tools is well-scoped for a b-roll search and timeline insertion server: search, download, and three output methods. Each tool earns its place without being redundant.
The core workflow (search, download, insert into timeline) is covered. Minor gaps exist: no tool for managing downloaded assets (e.g., listing, deleting) or for more advanced timeline operations (e.g., insert at specific point). Still, the main purpose is well-served.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your video workflows to cloud storage. Organize and access video assets across projects wi…
Edit video by talking to your AI — search footage, cut timelines, apply effects, add captions.
Search, inspect, organize, annotate, share, and automate creative assets in Shade.
Upload, organize, search, and transform images, videos, and files with AI-powered tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TLM-Repos/broll-studio-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
