Skip to main content
Glama

score_my_video

Put music on a video and hand back the finished file. Give a link to the video and a brief, and this measures the video, picks the AINSOF cue that fits its exact length and edit pace, mixes it underneath any existing dialogue at a level that keeps speech clear, and returns an MP4 the user can download and watch. Accepts a direct video URL or a Dropbox or Google Drive share link; for YouTube, Vimeo, Dailymotion or Twitch we cannot pull the file, so ask for the file itself or use get_upload_link. Pass track_id instead of a brief when the user has already chosen a cue. DIRECTING THE SCORE. A user who says what they want at each moment — "big opening, then pull back when she reads the letter, then build to the last shot" — is describing sections, not one brief. Pass a list of {from, to, brief} and each act gets its own cue chosen from its own words; add track_id, version or stems to an act to pin it exactly. Use silences for the opposite move — a moment the music stops dead. Both are snapped onto the video's real shot boundaries, so a boundary lands ON the cut. Call analyze_video first if you need the cut list to place them. To revise a score, call again with the same arguments and change only what the user asked to change — the response tells you how. Rendering takes about a minute, so the first reply is often { ok: false, error: "still_running" } — that is normal and not a failure. Call it AGAIN with the same arguments; it picks up the render already in progress rather than starting a second one. A genuine failure comes back as error "video_failed" with a reason to pass on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefNothe music you want, IN ENGLISH
versionNoforce a version — MAIN, CUT_30, CUT_60…
sectionsNoDIFFERENT MUSIC FOR DIFFERENT PARTS OF THE STORY. Use this when a brief asks for acts, distinct sections, a change of character, or a separate cue for a specific sequence. Each section gets its own cue chosen from its own brief, and every boundary is snapped to a real shot boundary so the music turns over on the cut. This is the ONLY way to make a moment feel different. There is no volume automation in this tool and there will not be: turning one piece of music down to fake a low point is not scoring, it is the same music played quieter, and it sounds like it. If a moment needs to feel smaller, give it its own section with its own brief.
silencesNoMOMENTS WHERE THE MUSIC STOPS DEAD. Briefs ask for this in as many words — "drop the music out completely when the statue is destroyed" — and it is the single most effective thing a score does. Each time is snapped to the nearest real shot boundary, so the stop lands ON the cut instead of near it. Call analyze_video first if you need the cut list.
track_idNouse this exact cue instead, e.g. 'AIN-CAT 006_004'
video_urlYeslink to the video
music_offset_dbNohow far under the video's own audio the music sits, in dB. Negative is quieter; 0 is level with it. Leave unset for the default.

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses important runtime behavior not visible in annotations: rendering takes about a minute, the first reply may be { ok: false, error: 'still_running' } and is normal, retrying with the same arguments resumes the existing render, and genuine failures return error 'video_failed'. It also explains internal behavior like measuring video, mixing under dialogue, and snapping boundaries to shot cuts.

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 long but well-structured with clear paragraphs for workflow, limitations, sections, silences, revision, and retry behavior. There is some repetition (e.g., shot-boundary snapping mentioned twice), but the complexity of the tool justifies the length and the information is densely valuable.

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, no output schema, and 7 parameters, the description is remarkably complete. It covers all input modes (URL, track_id, sections, silences), handles error cases, directs the agent to sibling tools when needed, and even explains the retry protocol. The only missing piece is an explicit output format, but the description references response fields like ok and error in context.

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?

Schema coverage is 100%, but the description adds substantial semantic detail beyond the schema: it explains how sections map to distinct moments with examples, clarifies silences as 'music stops dead', distinguishes track_id vs brief, and describes how music_offset_db affects mixing. This richly compensates for any ambiguity in the raw parameter names.

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 verb+resource statement: 'Put music on a video and hand back the finished file.' It goes on to explain the full workflow (measures video, picks cue, mixes, returns MP4) and distinguishes itself from siblings by explicitly referencing get_upload_link and analyze_video for related but different tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance and alternatives: it states that YouTube/Vimeo/Dailymotion/Twitch links cannot be pulled and tells the agent to ask for the file or use get_upload_link. It also says to call analyze_video first if the cut list is needed, and explains the retry behavior for still_running. This goes well beyond generic usage hints.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation3/5

search_music, find_soundtrack, and search_by_reference all discover catalogue music, and find_soundtrack overlaps with search_music for description-based requests. The long descriptions clarify the intended input type, but an agent could still reasonably pick the wrong tool when a user asks for music for a video.

Naming Consistency3/5

Most tools follow a readable verb + object pattern (analyze_video, deliver_score, get_track, get_upload_link), but others are noun phrases (cue_sheet, listen_link, feedback) or awkwardly different (about_ainsof, score_my_video). The naming is not chaotic but lacks a single consistent convention.

Tool Count5/5

With 12 tools, the set is within the well-scoped 3-15 range and each tool addresses a clear stage of the catalogue and scoring workflow: search, preview, upload, analyze, score, deliver, and feedback. No obvious filler or redundancy bloating the count.

Completeness4/5

The set covers the core lifecycle from music discovery and video analysis through scoring, delivery, and user feedback. Minor gaps exist such as no explicit browse/album listing tool, but search_music can retrieve albums and composers, so this should not cause agent failures.

Resources