Skip to main content
Glama

Say It Again

by ai.sayitagain
OverviewDiscussionsAdmin

Make a video

make_video
Destructive

Make a UGC video of a product. This spends the team's credits: the price quote_video gives for the same choices, refunded if the video fails. Answers an id at once, and with languages an id for each language in ids: call get_video with each about once a minute until its status is ready or failed, which takes a few minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
adNoAn ad to build the video like, its moves made for this product: a link of an ad in the Meta Ad Library, an ad's id from list_ads or the library, or one of the team's own videos as v- and its id from get_video, with - and its part after for any but its first. A library link not seen before is looked up in the library and counted against the team's ad links of the day. Not with lines or script_id.
keepNoWhat to keep of the ad: structure, the default, or pacing, its pace and its shots alone.
sizeNoThe shape the video is filmed in. 9:16 is the default.
angleNoThe angle the video argues: auto, the default, or one of the angle ids read_product lists for the product. Not with lines, script_id or ad, which argue their own.
countNoHow many videos to make, each a different take. Not with a script, which is made once for each presenter.
linesNoLines for the presenter to say, one a shot: 3 to 5 for a 15-second video, up to 10 for 30 seconds. They are said word for word as sent, not translated, and read by no check of ours. With script_id they replace that script's lines in order. Every person in the ads we make, on camera or heard as a voice, is made by AI and is not a customer. Nothing in an ad may present them as someone who has used the product, because that is a fake testimonial and the law forbids it. So they have no past with it: no time spent with it, no result it has had on their own body, home, pet or life, no before and after of their own, no having bought it, and no job, family role or other identity that makes them sound like a real customer. What they have is the moment: showing the product, using it on camera and reacting to what it does there, saying what it is and what it does, and the facts the product page gives.
photosNoPhoto links from read_product to film the product from.
scriptNoWhich of its scripts, from 1. 1 by default.
creditsYesThe credits quote_video gave for these choices; a different figure is refused.
productYesThe product's id from read_product, or the product's link.
qualityNofast (the default) or best.
secondsNoThe length: fast videos are 15 seconds, best videos 15 or 30 seconds.
captionsNoCaptions of what is said, on screen. On by default.
languageNoThe language the video is spoken in. Left out, the team's ad language.
languagesNoUp to 3 languages to make a script in at once, each its own video at one video's price, the first taking the place of language. Only with script_id, and not with language or lines; a script with words said as typed is made in one language, and the Arabic dialects go together, apart from every other language.
placementNoWhere the product is in the video. auto by default.
script_idNoThe id write_scripts answered, to make one of its scripts as a video.
presentersNoPresenter ids from list_presenters. Left out, one is chosen for the product.
descriptionNoDescribe the video: where it happens, what happens and the point it gets across. Words it gives someone to say, in quotes or not, are said as written and follow the rule given for lines.
video_styleNocasual (the default), professional or energetic.
idempotency_keyYesAny string unique to this video. Calling again with the same key and the same arguments answers as the first call did and spends nothing more.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotation-flags destructive, openWorld and non-idempotent are all backed with concrete behavior: it spends the team's credits, the amount is the quote quote_video gave for the same choices, and it is refunded if the video fails. It also discloses that the call returns immediately with an id rather than the finished video, that generation takes a few minutes, and how to poll — the exact context 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.

Conciseness4/5

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

Three sentences, cost first, then the async return and polling instructions — well front-loaded with no filler. The phrasing is verging on over-compressed ('Answers an id at once, and with languages an id for each language in ids'), which costs a little readability.

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 21-parameter, no-output-schema generation tool, the description covers the two things the schema cannot: the credit cost/refund model and the asynchronous handoff to get_video. The many parameter interactions (ad/angle/lines/script_id exclusions, language vs languages) are left entirely to the schema, which is acceptable given 100% coverage but leaves the description thin for a tool this complex.

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% and each of the 21 parameters carries its own rules, so the schema does the heavy lifting. The description only adds that 'the same choices' must match the quote and that `languages` yields one id per language; it adds no further syntax or mutual-exclusion guidance beyond what the schema already states.

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?

Opens with a concrete verb and resource ('Make a UGC video of a product'), which immediately separates it from siblings like change_video, make_longer, quote_video and get_video. The agent knows exactly what artifact this produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names quote_video as the source of the credit figure and get_video as the polling path with a cadence ('about once a minute'), so the surrounding workflow is clear. It stops short of explicit exclusions such as when to prefer change_video or make_longer over a fresh generation, leaving some routing to inference.

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

All Say It Again 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