Skip to main content
Glama

Update karaoke visuals

update_karaoke_visuals
DestructiveIdempotent

Apply the user's selected PNG, JPEG or WebP background and/or supported visual settings to this same project. A draft is saved without starting; a prepared project rebuilds only the MP4, reusing its music and timing. Import only a file the user selected for this task; a ChatGPT-generated image must have an actual host-provided file reference. Do not invent image URLs. This does not generate a new background or rerun audio alignment. Use the current revision and the same key after a lost response. Discuss changes in chat; display show_karaoke only when the new MP4 is ready.

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": {
      "project_id": "<project_id>",
      "expected_revision": "<expected_revision>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "update_karaoke_visuals"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYes
background_fileNo
idempotency_keyYes
visual_settingsNo
expected_revisionYes

Output Schema

NameRequiredDescriptionDefault
errorNo
mediaNo
quoteNo
stageNo
statusNo
visualNo
projectNo
progressNo
can_retryNo
can_startNo
demo_modeNo
can_cancelNo
project_idNo
studio_urlNo
can_handoffNo
lyrics_sourceNo
preview_readyNo
visual_sourceNo
visual_warningNo
command_versionNo
project_revisionNo
can_replace_lyricsNo
can_update_visualsNo
visual_preferencesNo
needs_lyrics_reviewNo
lyrics_search_outcomeNo
lyrics_search_providerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent=true and openWorldHint=true, yet the description adds real behavioral context: a draft is saved without starting, a prepared project reuses its music and timing and rebuilds only the MP4, and no audio alignment is rerun. The gap is replacement semantics — it never states whether the supplied background or settings overwrite the existing ones (the schema calls it a 'patch'), which matters given destructiveHint=true.

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 primary action and its two modes are front-loaded, followed by guardrails in short imperative sentences. Density is high and nearly every clause carries information, though the sequence of warnings and next-step routing could be grouped more tightly.

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 five-parameter mutation tool with nested file and settings objects, the description covers operating modes, side effects, idempotency and revision concurrency, and an output schema exists so return values need not be explained. What remains unstated is whether existing background/settings are replaced or merged, the one detail an agent most needs before invoking a destructive update.

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 description coverage is 0%, so the description must carry the load, and it does for most params: accepted image formats and the host-provided file reference requirement for background_file, 'the current revision' for expected_revision, and 'the same key after a lost response' for idempotency_key. It contributes nothing specific about visual_settings beyond 'supported visual settings', leaving the patch fields to the schema's enums.

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 first sentence names a specific verb (apply) and concrete resources (user-selected PNG/JPEG/WebP background and/or visual settings) on a named scope (this same project). It then distinguishes the two operating modes (draft saved without starting vs. prepared project rebuilding only the MP4) and explicitly excludes adjacent behaviors ('does not generate a new background or rerun audio alignment'), so an agent can separate it from prepare_karaoke and show_karaoke.

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?

It gives explicit when-to guidance (apply an already-selected file to the same project), when-not constraints ('Import only a file the user selected for this task', 'Do not invent image URLs'), and routes the agent onward to show_karaoke only once the new MP4 is ready. The lost-response path ('Use the current revision and the same key after a lost response') is a rare and valuable procedural instruction.

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.

Resources