Skip to main content
Glama

agent-media

quote_ugc

Read-onlyIdempotent

Price an optional make_ugc workflow and check the spendable balance without rendering or using credits. Pass the exact input intended for make_ugc. Show the returned price to the user and only call make_ugc after the user has authorized that spend.

Input Schema

NameRequiredDescriptionDefault
lookNonatural
nameNoName/age/vibe hint, e.g. 'Sophia, 28'.
imageNoA photo of the person, an https URL. The face is locked to it. If you only hold bytes, call `upload_image` first and pass the URL it returns; base64 is still accepted here but it is printed into the user’s chat and re-sent on every retry.
musicNo
sceneNoWHERE the video happens, in a few words: 'on a sunny beach, sea behind her', 'in a gym by the weights', 'in bed at night with a lamp on', 'in a parked car'. Set it whenever the user names a place. Without it the video is set in an ordinary room.
personNoDescribe the person in words. Omit if you pass image or character.
scriptNoWhat the person SAYS (lip-synced), any length. A one-liner makes one clip; a full monologue makes the full multi-take video automatically, never trimmed. Usually the only field you set. EXCEPTION: when you also pass product_image the video is a SINGLE take of at most 15s, so the script must be 46 words or fewer.
captionsNoBurn in TikTok/Hormozi captions. OFF unless set true, ASK the user whether they want captions (and which caption_style) before generating; never add captions unprompted.
durationNoIGNORED when `script` is set: length follows how long the words take to say (~2.9 words/sec; one take: up to 15 words → 5s, up to 31 → 10s, up to 46 → 15s; longer scripts become several takes sized the same way). A video is never stretched to reach a requested duration; silence between takes and at the end is cut, so the final video runs about as long as the speech. To get a longer video, write more words (~2.8 words per extra second). The response's take_plan shows the takes. Only used for a silent `scene_action` clip, which has no words to measure.
broll_urlNoA b-roll / gameplay / product video overlaid on the lower half while the person narrates.
characterNoReuse a saved character: its character_id (char_…) OR its character_sheet_url from list_characters.
aspect_ratioNo9:16
scene_actionNoA silent action clip (dancing, b-roll, vibes), no dialogue. Use instead of script; needs a `character`.
caption_styleNohormozi
product_imageNoA photo of a PRODUCT to show/hold/wear, an https URL. If you only hold bytes, call `upload_image` first and pass the URL it returns: base64 travels inside this tool call, is printed into the user’s chat, and is re-sent on every retry. Turns the video into a product ad; needs a `character` to hold it, and limits `script` to ONE take of at most 15s (46 words).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint true and destructiveHint false, and the description adds real context beyond that: no rendering, no credit consumption, and a balance check. It does not say whether a quote expires or what happens on invalid input, so it stops short of full disclosure.

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?

Three short sentences, no repetition, and the safety-critical instruction (authorize before spending) lands at the end where it is most salient. Every sentence carries an instruction the agent must act on.

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 15-parameter, no-output-schema tool, the description correctly frames inputs as make_ugc's payload and mentions the 'returned price' as the output. Missing only edge-case behavior (quote staleness, error responses) for full completeness.

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?

With 73% schema coverage the schema carries most of the burden, but the description adds a critical semantic the schema can't: the parameters are the exact make_ugc input, i.e. this call must mirror that tool's payload. Individual parameter behavior is left to the rich schema.

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?

Opens with a specific verb+resource ('Price an optional make_ugc workflow and check the spendable balance') and explicitly distinguishes itself from make_ugc by noting it runs 'without rendering or using credits'. The only gap is the sibling 'quote', which is never mentioned, leaving the general-vs-UGC quoting split implicit.

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 workflow: pass the exact input intended for make_ugc, show the price to the user, and only call make_ugc after authorization. That is a when-to-use rule and a hard gate on the alternative, not an inference.

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