Skip to main content
Glama

Vidova

by ai.vidova
OverviewDiscussionsAdmin

Generate music

generate_music

Generate music from a prompt, for 10, 20, 30 or 60 seconds: the track comes back that long. First search_stock with kind music: Vidova's licensed library has measured beds for ads, reels, talking heads and promos at no cost; generate only when no track fits. forceInstrumental true excludes singing. Use generate_sfx for sound effects. The music does not play its hits at seconds a prompt asks for: describe its shape (a quiet stretch, then one big drop, then the full sound) and give hero instead. It answers at once with a Job ID and the media is made in the background: start every generation you need, keep working, then call wait_for_jobs with all their Job IDs to get each Asset ID for patch_film. With its Asset ID come its beat and hits, measured from the track: the tempo, the beat times, the downbeats (bar starts), the big hits (where the music slams in), the drops, the loudness of each second, the sections (intro, build, drop, breakdown, outro), the drum hits between beats and the fills (quick runs of hits into the next bar). Cut on these measured times. With hero, it also says where the strongest drop or big hit is and the clip that lands it on that second. Uses about 0.95 credits a second: 60 seconds use 57 credits. A credit refusal says how many credits are left: retry only with a duration that fits.

Input Schema

NameRequiredDescriptionDefault
heroYesThe film second of the edit's hero moment, the reveal the music must hit, or null. The answer says which offset slides the track's strongest drop or big hit onto that second.
promptYesUp to 2000 characters.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.
durationSecondsYes
forceInstrumentalYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / hero
      Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The film second of the edit's hero moment, the reveal the music must hit, or null. The answer says which offset slides the track's strongest drop or big hit onto that second."
+}
    • changedInput schema / required
      Previous value: -[
-  "prompt",
-  "durationSeconds",
-  "forceInstrumental",
-  "projectId"
-]New value: +[
+  "prompt",
+  "durationSeconds",
+  "forceInstrumental",
+  "hero",
+  "projectId"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare it as a non-readonly, non-idempotent, open-world write; the description adds the critical operational facts: it returns a Job ID immediately while media renders in the background, requires wait_for_jobs with all Job IDs to obtain Asset IDs, costs about 0.95 credits per second (57 for 60s), and what a credit refusal means. It also discloses the analysis payload returned with the Asset ID (tempo, beats, downbeats, drops, per-second loudness, sections, fills) so the agent knows what it gets back.

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?

Front-loaded with the core action, duration options, and the search_stock-first rule. It is dense and long, but for a tool with no output schema most sentences (async job flow, cost, returned beat data) are load-bearing; the return-field enumeration is the one stretch that could be tightened.

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?

A generative, credit-spending async tool with no output schema, and the description covers all the gaps that matter: alternatives, cost, async lifecycle, failure mode on credit refusal, and the full shape of the returned analysis. Nothing an agent needs in order to call it correctly and consume the result is missing.

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?

Adds real meaning beyond the 60%-coverage schema: forceInstrumental true excludes singing, hero is explained as the film second the strongest drop must land on plus the returned offset, and the description clarifies that prompts cannot place hits at exact seconds and should describe shape instead. prompt's content strategy and duration are covered; projectId semantics live only in the schema, which keeps this from a 5.

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 and resource ("Generate music from a prompt") plus the constrained output lengths, and explicitly distinguishes itself from search_stock and generate_sfx in the same breath. An agent can tell exactly what this produces versus its nearest siblings.

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?

Gives an explicit routing rule with a preferred alternative and its argument: "First search_stock with kind music... generate only when no track fits", and "Use generate_sfx for sound effects." It also states when to use hero versus second-by-second prompt requests, which is a genuine when/when-not decision.

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

All Vidova 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