Skip to main content
Glama

Quote a faceless video

quote_faceless
Read-only

Estimates the credit cost of a faceless video before rendering, so you can show users the price without spending credits.

Instructions

Estimate the credit cost of make_faceless WITHOUT spending credits. Always call this first and show the user the price before make_faceless.

Input Schema

NameRequiredDescriptionDefault
briefNoWhat the video is about; the narration is written from it. Required when input_mode is 'brief'; must be absent when it is 'script'.
voiceNoNarration voice: a name from list_voices with skill=make_faceless (kind faceless_voice). Omitted means narrator_en_wise_lady. Choose a voice in the language of the narration: a voice reads any language, with the accent of its own. The API refuses an unknown name and a make_ugc voice before any charge. A raw voice_id is not accepted here.
scriptNoThe narration, read as written. Required when input_mode is 'script'; must be absent when it is 'brief'.
captionsNoBurned-in captions; on by default.
input_modeYes'script' narrates your exact text; 'brief' writes the narration from a short description. Send exactly one of script or brief, matching this mode.
scene_imagesNoOptional images of your own, each placed at a word range or quote of the narration.
style_referenceNoOptional public https image whose visual style the scenes follow.
duration_secondsYesSelected length, 30 to 90 seconds, on a 1/25 s frame boundary. The video ends with its narration and runs at least 25 seconds, usually at most a quarter past the selection and 90 seconds; when the narration takes longer, the video runs to its end. A video more than 5 seconds longer than the selection says so in warnings[]. The charge never exceeds the quote. A script is accepted when its estimated length is 21 seconds to the selection plus 5, at most 90.
character_detailsNoOptional fixed visual details for the referenced person or figure, such as hairstyle, clothing and absent accessories; applied to every generated scene.
character_referenceNoOptional public https image of a person or figure to keep consistent across scenes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.36.0
    • changedInput schema / properties / duration_seconds / description
      Previous value: -"Selected length, 30 to 90 seconds, on a 1/25 s frame boundary. The video ends with its narration, runs at least 25 seconds and may exceed the selection by up to a quarter, never beyond 90 seconds; a video more than 5 seconds longer says so in warnings[]. The charge never exceeds the quote. A script is accepted when its estimated length is 21 seconds to the selection plus 5, at most 90."New value: +"Selected length, 30 to 90 seconds, on a 1/25 s frame boundary. The video ends with its narration and runs at least 25 seconds, usually at most a quarter past the selection and 90 seconds; when the narration takes longer, the video runs to its end. A video more than 5 seconds longer than the selection says so in warnings[]. The charge never exceeds the quote. A script is accepted when its estimated length is 21 seconds to the selection plus 5, at most 90."
  2. Changed3 schema fields changedv0.27.0
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / duration_seconds / description
      Previous value: -"Selected length, 30 to 90 seconds, on a 1/25 s frame boundary. The video ends with its narration, runs at least 25 seconds and may exceed the selection by up to 5 seconds, never beyond 90 seconds. The charge never exceeds the quote. A script must fit this output range."New value: +"Selected length, 30 to 90 seconds, on a 1/25 s frame boundary. The video ends with its narration, runs at least 25 seconds and may exceed the selection by up to a quarter, never beyond 90 seconds; a video more than 5 seconds longer says so in warnings[]. The charge never exceeds the quote. A script is accepted when its estimated length is 21 seconds to the selection plus 5, at most 90."
    • addedInput schema / properties / voice
      Added value: +{
      +  "description": "Narration voice: a name from list_voices with skill=make_faceless (kind faceless_voice). Omitted means narrator_en_wise_lady. Choose a voice in the language of the narration: a voice reads any language, with the accent of its own. The API refuses an unknown name and a make_ugc voice before any charge. A raw voice_id is not accepted here.",
      +  "pattern": "^[A-Za-z0-9][A-Za-z0-9_-]{0,63}$",
      +  "type": "string"
      +}
  3. Changed1 schema field changedv0.25.0
    • addedInput schema / properties / character_details
      Added value: +{
      +  "description": "Optional fixed visual details for the referenced person or figure, such as hairstyle, clothing and absent accessories; applied to every generated scene.",
      +  "maxLength": 400,
      +  "minLength": 1,
      +  "type": "string"
      +}
  4. Addedv0.21.1

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description usefully adds that no credits are consumed, which is the key behavioral fact. However, it says nothing about whether the quote is binding or how priced inputs (duration, voice, scene images) affect the estimate, and no output schema exists to cover the returned cost breakdown.

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?

Two short sentences, zero filler, with the cost-free framing and the ordering rule both front-loaded.

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 read-only estimator whose 10 parameters are fully documented in the schema, the description covers purpose and call ordering adequately. It would be stronger if it stated that the quote mirrors make_faceless inputs and described the shape of the returned cost estimate, since no output schema exists.

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 description coverage is 100% across 10 parameters, so the schema fully documents each field. The description adds no parameter-level guidance (e.g., that it accepts the same arguments as make_faceless), so baseline 3 applies.

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+resource: estimate the credit cost of make_faceless, and adds the distinguishing scope 'WITHOUT spending credits'. An agent can immediately separate it from make_faceless and the other quote_* 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?

Explicitly prescribes the workflow: 'Always call this first and show the user the price before make_faceless.' That is both a when-to-use rule and the required follow-up action, leaving nothing to inference.

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