Skip to main content
Glama
Sign In

CutClip.one

by one.cutclip
OverviewDiscussionsAdmin

music.compile_prompt

Preview what music.generate would send to Lyria for a placeholder — prompt, length, model and cost. Free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "placeholderId": "<placeholderId>"
    },
    "name": "music.compile_prompt"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelNolyria-3-clip (30 s) or lyria-3.5 (full song); defaults by the clip's length
lyricsNoWords to sing, with optional [Verse]/[Chorus] tags. Ignored when instrumental
promptNoGenre, mood, instruments, tempo. Defaults to the clip's prompt, then the scene's music prompt
projectIdYes
instrumentalNo
placeholderIdYesA music or ambience placeholder on an audio track (timeline.add_placeholder; scenario.apply_to_timeline makes a "Score" one)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral load. It usefully discloses that nothing is charged ("Free") and enumerates what is returned (prompt, length, model, cost), which implies a read-only, non-generating operation. It does not state side-effect freedom outright, nor whether validation errors occur for invalid placeholders or whether the preview is cached/fresh.

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?

A single front-loaded sentence — the preview framing comes first, then the returned fields, then the cost note. Nothing is redundant and the sibling reference is packed into the opening clause.

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?

For a six-parameter read-only preview tool with no output schema and no annotations, the description covers the essentials: what it mirrors, what it returns, and that it costs nothing. Minor gaps remain around prerequisites (valid placeholder on an audio track) and error behavior, but the schema fills in most of that.

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 67%, with good per-parameter descriptions for model, lyrics, prompt, and placeholderId (including its origin tools). The description adds almost no parameter-level meaning beyond "for a placeholder" — it does not explain the projectId/placeholderId pairing or the defaulting order it depends on, though the schema already covers much of that. Baseline 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?

States a specific verb ("Preview") plus the exact resource (what music.generate would send to Lyria) scoped to a placeholder. It explicitly names the sibling music.generate it is a preview of, so the agent can separate preview from the paid generation call without opening either schema.

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 framing "preview what music.generate would send" plus "Free" clearly implies when to use it: before committing to a real generation, to inspect prompt/length/model/cost at no charge. It does not spell out exclusions (e.g. that it cannot be used to actually produce audio, or how it relates to shot.compile_prompt), so it stops short of full when/when-not guidance.

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

All CutClip.one toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources