Skip to main content
Glama

Say It Again

by ai.sayitagain
OverviewDiscussionsAdmin

Price a video

quote_video
Read-only

What a video with these choices costs in credits, and whether the team's balance covers it. Free.

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.
scriptNoWhich of its scripts, from 1. 1 by default.
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.
video_styleNocasual (the default), professional or energetic.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuinely decision-relevant trait not in the annotations: the call itself is 'Free', and it returns a balance-coverage verdict rather than performing the action. It does not address the openWorld implication of looking up unseen library ad links, but against an already-covered safety profile this is a solid addition.

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 sentences, zero waste, with the core purpose front-loaded and the cost trait isolated for emphasis. Nothing is repeated from the schema or annotations.

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, zero-required tool the schema carries nearly all the load, and with no output schema the description usefully states what is returned (cost in credits plus a balance-coverage verdict). The only real gap is sibling routing: it never tells the agent this is the non-committal step before make_video.

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 the 15 parameter descriptions are unusually rich (defaults, mutual exclusions, per-param behavior). The description adds no parameter-level meaning beyond 'these choices', so the baseline 3 for a fully documented schema is correct.

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 description names a concrete function: it computes the credit cost of a video built from the given choices and reports whether the team's balance covers it. That is a specific verb+resource, not a restatement of the name. It does not, however, name or contrast itself with the obvious sibling make_video, so the agent must infer the quote-vs-execute distinction.

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

Usage Guidelines3/5

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

The single word 'Free' strongly implies this is a zero-cost preview to run before make_video, which is usable implied guidance. But there is no explicit when-to-use, no 'use this before X', and no exclusion statement, so the routing to make_video or get_balance is left 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