Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

Make the film

make_studio_video

Press the film's one button: make everything its storyboard asks for that is not made yet (new or changed scenes, paid scene changes). A film with a voiceover is ONE press: the button (voice_with_film: true) records the voiceover and makes the film cut to it, priced in one quote. Only when the user asks to hear the read first, press button.voice_first instead (its own quote_hash and credits): that records ONLY the voiceover (voice_only: true) — poll until storyboard.layers.voice.take.url is set, let them listen, then (with their go-ahead on the new button price) press again to make the film cut to that read. The same applies when button.step is "voice". If they change a spoken line after it, the take goes stale and the button re-reads it first. An ad or reel shot picture-first gets its voiceover LAST: once the picture is done the button's step is "voice_after" — this press records the voiceover fitted to the finished scenes and puts it on the film by itself (poll until storyboard.layers.voice.take is set and ready again). The initial storyboard make and separately approved voice-after press spend Creative Credits against this connection's daily cap; requested automatic edits use an active persistent editing cap and report their own charge. NEVER call it without the user's explicit go-ahead on that price: in a chat with approval cards, proposing it puts that price on the card and the Approve is the go-ahead (do not also write the label as text); elsewhere, first show them get_studio_video button.label and button.lines. Send button.quote_hash and button.credits as expected_credit_cost. If the storyboard changed since, nothing is made or charged and the answer carries the new button to confirm again; a cost that is not the button's is refused. Optional budget_credits authorizes this film's persistent automatic-edit cap when none is active; it does not charge or reserve the unused amount, and it applies to requested paid edits after this press. If a cap is already active, this value must match it (use set_studio_video_edit_budget to change it). Requested edits within an active cap do not require another Make approval, including requested voice or music edits. It answers within about 40 seconds: started: true (with credits_charged: null) means the press is under way and did not finish answering in time — do NOT press again; poll get_studio_video. Afterwards poll get_studio_video until ready.

Input Schema

NameRequiredDescriptionDefault
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
project_idYesProject id from create_motion_project. The bare project id or the library id ("studio-video:<uuid>" from list_creations / find_creation) both work.
quote_hashYesbutton.quote_hash from get_studio_video
budget_creditsNoPersistent cap for requested automatic edits when no cap is active; unused credits are never charged
expected_credit_costYesbutton.credits — the price the user agreed to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Project id from create_motion_project"New value: +"Project id from create_motion_project. The bare project id or the library id (\"studio-video:<uuid>\" from list_creations / find_creation) both work."
    • removedInput schema / properties / project_id / format
      Removed value: -"uuid"
    • addedInput schema / properties / project_id / pattern
      Added value: +"^(?:studio-video:)?[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"
  3. Changed1 schema field changed
    • changedInput schema / properties / budget_credits / description
      Previous value: -"Total allowance for this press plus automatic retakes, only when the user chose it"New value: +"Persistent cap for requested automatic edits when no cap is active; unused credits are never charged"
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnly=false, openWorld=true, idempotent=false and destructive=false; the description goes far beyond by disclosing that credits are charged against a daily cap, that requested auto-edits use a persistent editing cap, that stale quote hashes cause nothing to be made or charged, and that the tool answers in ~40s with `started: true` meaning do not press again. These are exactly the expensive, irreversible, retry-hazard behaviors annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the safety rule are reasonably front-loaded, but the body is a dense, punctuation-heavy run of voiceover, quote-hash, cap and timeout rules where several sentences chain multiple conditionals. Almost every sentence carries operational information, yet the lack of structure (no separation of approval, pricing, polling, and modes) makes it harder to scan than its length alone would justify.

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?

For a non-idempotent, credit-charging, open-world tool with no output schema, the description covers the full lifecycle: pricing and approval, quote-hash staleness, budget cap interaction, the 40-second non-response case with `started: true` / `credits_charged: null`, voice_first polling markers, and the required follow-up polling until `ready`. Nothing an agent needs in order to call it safely 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?

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top — it tells the agent to send `button.quote_hash` and `button.credits` as `expected_credit_cost`, explains that a mismatched cost is refused, and details that `budget_credits` authorizes a persistent cap without charging or reserving unused amount and must match any already-active cap. That is substantial semantic value beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a concrete verb and resource — press the button to make everything the storyboard asks for that isn't made yet — and clarifies the voiceover variants rather than restating the title. It implicitly separates the press from the polling counterpart (get_studio_video) and from set_studio_video_edit_budget, but the purpose is buried under a large amount of branching mode logic, which slightly dilutes the first-read signal.

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?

Explicit routing is provided throughout: use `button.voice_first` only when the user wants to hear the read first, press once when voice and film should be one quote, handle `button.step` of "voice" or "voice_after" differently, and poll get_studio_video instead of re-pressing. It also states the hard prerequisite (never call without explicit go-ahead on the price, propose via approval card or show button.label/lines), which is exactly the when-to-use guidance an agent needs.

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

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