Skip to main content
Glama

Kleo

by com.kleooai
OverviewDiscussionsAdmin

Server Details

Narrated 4K 60 fps films from a brief, realistic or animation, made from your assistant via MCP.

Ownership verified
Status
Healthy
Uptime
99.1% over 21 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
tonnooooo/kleo-mcp
GitHub Stars
0

TDQS

A4.1/5.0

Scored across 12 tools

Disambiguation4/5

Tools are largely distinct, each targeting a specific phase like account, adapt, storyboard, create, monitor, or result. However, kleo_get_job, kleo_wait_for_video, and kleo_get_result overlap in reporting progress and returning download links, which could cause misselection. Descriptions mitigate this by prescribing usage patterns, but the boundary is not perfectly crisp.

Naming Consistency4/5

All tools use the kleo_ prefix and snake_case, which is highly predictable. Minor deviations exist: kleo_account and kleo_storyboard_guide are noun phrases while most are verb_noun, and kleo_redeem is a bare verb. Still, the convention is consistent enough for easy identification.

Tool Count5/5

12 tools fit the video generation lifecycle well, covering account, prompt adaptation, storyboard, creation, monitoring, results, cancellation, and references. No tool feels redundant except the non-functional kleo_generate_thumbnail, but its inclusion as a beta placeholder is documented and doesn't inflate the set unreasonably.

Completeness5/5

The surface covers the full lifecycle from account and credits through prompt adaptation, storyboard guidance, reference upload, video creation, job monitoring, result retrieval, and cancellation. No obvious gaps for the core workflow; even listing past videos is handled by kleo_get_job without a job_id. The only unavailable tool (generate_thumbnail) is explicitly documented as not yet functional, so it doesn't create a dead end.

Available Tools

12 tools
kleo_accountAccount and creditsA
Read-onlyIdempotent
Inspect

The credits left on this account, whether it can order a FILM (has_paid: films are for accounts that have bought a pack, or film_trial: the one free 15-second film a launch code opened; every account can order the animatic), the account's invitation link (referral: a friend who joins through it and buys a first pack earns both of you credits), the link to its page, and the "Kleo key" that carries the same account (and the same credits) to another browser or another computer. Call it before the first kleo_create_video of a conversation and when the user asks how many credits they have, how to get more, or how to use Kleo somewhere else. Give them account_url as a plain link: it opens a read-only page (balance, prices, where to write) and cannot sign anybody in. Show account_key only if they ask for it, because anyone who has it can take the account over and spend its credits.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish readOnlyHint/idempotentHint/openWorldHint=false, but the description adds substantial context beyond them: account_url opens a read-only page that cannot sign anyone in, and account_key is a credential that lets anyone take over the account and spend its credits, with guidance to reveal it only on request. These are meaningful safety and disclosure behaviors the annotations do not convey.

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?

Information is front-loaded (what it returns first, then when to call, then disclosure guidance) and every sentence carries content. It is somewhat dense and run-on, with heavy parenthetical nesting, which costs a point on structure.

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?

With no output schema, the description steps in to explain all returned values and their meaning, plus the security nuance around account_key. An agent has everything needed to call it and to present results safely.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description instead documents the semantics of the returned fields (credit meaning, film_trial vs has_paid, referral mechanics), which is valuable but not parameter semantics.

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?

The description names the specific resource (this account) and enumerates exactly what it returns: remaining credits, whether a FILM can be ordered (has_paid/film_trial), the animatic allowance, referral/invitation link, account page URL, and the Kleo key. This is far more precise than the title 'Account and credits' and clearly distinguishes it from siblings like kleo_create_video.

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?

It states explicit triggers ('call it before the first kleo_create_video of a conversation') and user-intent conditions (asking about credits, how to get more, how to use Kleo elsewhere), and names a sibling tool. When-to-use is unambiguous.

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

kleo_adapt_promptAdapt a video request into the film's spec and treatmentA
Read-only
Inspect

Step 1 (recommended). Reads the user's request against Kleo's intake and asks for what is missing — the film or the animatic (with this account's prices) and the narration's language (English or Italian) among it; once nothing is, turns it into the SPEC (the request taken apart into the requirements the finished film is checked against: who is in it and exactly how they look, where, what happens in which order, what must be seen, read or said, what must never appear — every item quoting the user) and then the TREATMENT of the film written under it (logline, angle, opening image, acts with their seconds, ending, visual language, pacing, narrator, motifs), listing every decision Kleo took that the user did not ask for. When the user described their film, the film is theirs: their characters as described, their events in their order. Takes the user's reference pictures (https links, or an upload token from kleo_upload_link) and answers with their handles and what they show. Nothing is charged and no GPU is rented. Then show the user what Kleo understood, the logline and the decisions, and pass the "spec" and the "treatment" — unchanged, or corrected as the user asked — to kleo_create_video.

ParametersJSON Schema
NameRequiredDescriptionDefault
toneNoThe tone the user asked for, when they said it.
musicNoThe user's answer about music, in their words: "no" (in any spelling) for none; "yes", or the kind they want (a mood, a genre, an instrument), for an instrumental track under the narration. Asked every time; pass their answer, never a guess.
styleNoThe look: "realistic" (filmed, cinematic) or "animation" (a 2D animated film). Read off the request when its words say it; otherwise the tool asks the user for it — pass their answer here.
authorNoWho writes the spec and the treatment. "assistant" (default): Kleo hands YOU the two methods and you write them — you are a far stronger writer than Kleo's own planning model, and it costs nothing. "server": Kleo's model writes them (use only if you cannot write JSON yourself).assistant
formatNo16:9 for YouTube/landscape, 9:16 for a Short/TikTok/Reel. Read off the request when its words say it; otherwise the tool asks the user for it — pass their answer here, never a guess.
promptYesThe user's request in their own words.
productNoThe user's answer to the question film or animatic, which the tool asks with this account's prices: "film" (every shot a generated clip, for accounts that have bought a pack) or "animatic" (the drawn frames with camera moves, 5 credits up to 20 seconds, 10 up to 60 seconds). Never a guess.
audienceNoWho the video is for, when the user said it.
languageNoThe user's answer to the question about the narration's language, in their words ("en", "English", "italiano"…): Kleo narrates in English or Italian, and "whatever" / "no preference" means English. Asked every time the request does not say it: pass their answer, never a guess, and never the language they write to you in.
must_keepNoWhat the user said must appear (names, numbers, places, a message) or must not, when they answered that question.
subtitlesNoThe user's answer about burned-in subtitles: "yes" for thin cinema subtitles in the video, "no" for none (an .srt file is delivered either way). Asked every time; pass their answer, never a guess.
ai_upscaleNoThe user's answer to the AI upscale question, in their words ("yes" / "no"): asked for a film only, with its price in extra credits. Only a clear yes buys it; "no", "whatever" or no answer means the classic 4K 60 fps finish. Never a guess.
duration_sNoLength in seconds. Read off the request when its words say it; otherwise the tool asks the user for it — pass their answer here, never a guess.
referencesNoThe pictures the user gave for this film, each with ONE of: url (a public https link), upload (the token of a kleo_upload_link link they uploaded through), handle (kref_… returned earlier); plus role and name when the user said what it shows. Kleo draws the characters, objects and places FROM these pictures.

TDQS

A4/5.0
Behavior4/5

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

Discloses cost ('Nothing is charged and no GPU is rented'), that it interrogates the user for missing intake fields, and that it returns reference handles naming what each picture shows. This adds real context beyond the readOnlyHint/openWorldHint annotations, which already cover the safety profile.

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?

Front-loads 'Step 1 (recommended)' and the core action, but the body is a sprawling multi-clause sentence with nested parentheticals that is hard to parse. Most content earns its place, yet it is materially longer and less structured than it needs to be.

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 14-parameter tool with no output schema, the description covers the flow, the two returned artifacts, reference handling, and the zero-cost guarantee. It is complete enough to invoke correctly, though a clearer statement of the exact return payload shape would close the remaining gap.

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 parameter (product, author, language, references, etc.) is fully documented in the schema itself. The description reinforces the 'pass their answer, never a guess' convention and adds conceptual framing for product/author, but offers little parameter-level detail the schema doesn't already provide.

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 and pair of artifacts (turn the request into the SPEC and the TREATMENT) and defines exactly what each contains. It self-identifies as 'Step 1' and routes onward, so an agent can place it in the pipeline vis-à-vis kleo_create_video without opening any 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?

Clearly establishes this as the first, recommended step and names kleo_create_video as the destination for the 'spec' and 'treatment' it produces. It stops short of stating when NOT to use it or naming an alternative path, but the sequencing guidance is explicit and actionable.

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

kleo_cancel_jobCancel a videoA
DestructiveIdempotent
Inspect

Cancels a video that is waiting or rendering. The credits are given back in full if it had not started, otherwise in proportion to the work left. A finished, failed or already cancelled video cannot be cancelled.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYesThe video number returned by kleo_create_video.

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already signal destructiveness and non-read-only behavior, and the description adds meaningful context beyond them: credit refund policy (full vs. proportional) and terminal states that make cancellation impossible. This gives the agent useful expectations about side effects and failure cases without contradicting the annotations.

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, each carrying necessary information: what the tool cancels, the financial consequence, and the non-cancellable states. The most important action is front-loaded, and there is no filler or repetition of the schema.

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 single-parameter cancellation tool with no output schema, the description covers the essential context: eligibility, credit impact, and invalid targets. The only minor gap is that it does not describe what the response looks like after a successful cancellation, but that is not critical given the tool's simplicity.

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?

The schema already fully documents the only parameter, job_id, including where it comes from ('returned by kleo_create_video'). The description adds no additional parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.

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?

The description opens with a specific verb and resource ('Cancels a video') and narrows the scope to videos 'waiting or rendering,' which clearly distinguishes it from sibling tools like kleo_get_job and kleo_create_video. It also states the intended effect in concrete terms, so an agent can determine what this tool does 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?

The description gives clear conditions for use: only waiting or rendering videos can be cancelled, and finished, failed, or already cancelled videos cannot be. It does not explicitly name an alternative tool, but the when/when-not guidance is concrete enough that an agent knows whether to attempt cancellation.

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

kleo_create_videoCreate a videoAInspect

Step 3. ASK FIRST, THEN CALL. Do not call this until the user has said, in their own words, what the video should be about. If the subject is YOUR idea and not theirs — you suggested a topic, or you filled a vague request in with your own guess — stop and ask them, and wait for the answer. A render spends a credit they cannot get back once it starts and takes about twenty minutes, so a video nobody asked for is not a fast answer, it is a wasted one. When their request is short but clear ("a Short about pirates"), that is enough: do not interrogate them. When it is missing the subject entirely, ask for the subject and nothing else. Starts rendering, in the chosen look (realistic or animation), either the FILM — every shot generated as moving footage from its own frame, narrated, 4K 60 fps; for accounts that have bought a credit pack (kleo_account → has_paid) — or the ANIMATIC of the same storyboard (product: "animatic": the drawn frames with the camera moving over each one, same narrator and layer, no generated clip; 5 credits up to 20 seconds, 10 up to 60 seconds, every account) — from a prompt, a length, a format and the user's two answers about music and subtitles (plus your storyboard from kleo_storyboard_guide, if you wrote one). The price follows the length for a film (1 credit buys 1.5 seconds of film, 10 credits minimum: 10 credits for a 15-second film, 20 for a 30-second Short, 40 for a minute, 200 for five minutes; an animatic of the same storyboard (the drawn frames with camera moves and the narration, no generated clip, up to 60 seconds) costs 5 credits up to 20 seconds, 10 up to 60 seconds); the tool answers with the exact credits before anything is charged, and a render takes 25-35 minutes on a rented GPU (an animatic fifteen to twenty). Returns at once with the video number (job_id), the estimated minutes (eta_min) and the credits used; the render runs on a GPU in the background. Tell the user the number and the estimate, then offer to check progress with kleo_get_job. Pass the "spec" and the "treatment" the user approved, the handles of their reference pictures as "references", their must_keep / audience / tone answers, and their "corrections" after the read-back in their own words when they gave any: the film is planned under the spec and every picture is checked against it. If the tool returns an error, nothing was charged: fix what it says and call again.

ParametersJSON Schema
NameRequiredDescriptionDefault
specNoThe SPEC you wrote under kleo_adapt_prompt's spec method (or the one it returned), corrected as the user asked: {v:1, mode, summary, cast, items, refs, open, narration, script}. Every item's "quote" must be the user's own words from the prompt, from their must_keep/audience/tone answers, or from their "corrections" after the read-back (pass those too). Checked before anything is charged; the film is planned under it and every picture is checked against it.
toneNoThe tone the user asked for.
musicNoThe user's answer about music, exactly as you passed it to kleo_adapt_prompt: "no" (or null) for none; "yes" or the kind they want for an instrumental track under the narration (the treatment's "music" brief is used when it has one). Kleo has the track composed by Suno and ducks it under the voice.
styleNoThe look: "realistic" (cinematic live action) or "animation" (a 2D animated film); both narrated; every shot starts as one frame drawn in that look — a generated clip in the film, a camera move over the frame in the animatic. Pass the treatment's "look"; when omitted the treatment decides, and realistic when nothing says.
voiceNoVoice id from kleo_list_templates (narrator-en-m, narrator-en-f, narrator-it-m, narrator-it-f). The engine ids used inside a storyboard (am_michael, af_heart, bf_emma, im_nicola, if_sara) are accepted too. Optional.
formatYes16:9 for YouTube/landscape, 9:16 for a Short/TikTok/Reel, as the user said or answered it. Required: Kleo never picks a frame for the user.
promptYesWhat the video is about, IN THE USER'S OWN WORDS (8 to 4000 characters): topic, angle, facts, names, tone, anything that must appear on screen. If you are about to write this field out of an idea of your own, that is the sign to ask them instead: the credit and the twenty minutes are theirs, so the subject has to be theirs too.
productNoThe product the user chose in the intake (kleo_adapt_prompt asks it, with the prices): pass it. What to make from the storyboard: "film" (default; every shot a generated clip, priced by length, for accounts that have bought a credit pack) or "animatic" (the same drawn frames with the camera moving over each one, the same narrator and layer, 4K 60 fps, no generated clip; 5 credits up to 20 seconds, 10 up to 60 seconds, every account). Say which one you are ordering to the user before you call.
audienceNoWho the film is for, as the user said it.
languageNoVoice and caption language: the narration language the user chose, as kleo_adapt_prompt's "language" returned it (the intake asks it; never the language of the chat). A storyboard you pass must declare this same language.en
templateNoOptional; the only one is "film" (realistic or animated, 16:9 for YouTube or 9:16 for Shorts; 15 to 300 seconds for a film, 15 to 60 for an animatic). Omit it.
must_keepNoThe user's answer to "what must appear, or must not", as passed to kleo_adapt_prompt.
subtitlesNoThe user's answer about burned-in subtitles: true/"yes" for thin cinema subtitles in the picture, false/"no" for none. An .srt file is delivered either way.
treatmentNoThe treatment object kleo_adapt_prompt returned for this request, unchanged or edited as the user asked (logline, angle, device, opening, ending, acts, visual, pacing, narrator, motifs, decisions, prose, variation). Kleo plans the direction and every scene under it. Checked before anything is charged; on error the tool lists the problems. Omit it and Kleo writes a treatment itself while planning — the user just never sees it first.
ai_upscaleNoThe user's answer to the AI upscale question kleo_adapt_prompt asked (film only): "yes" for Real-ESRGAN + RIFE on every shot, at the extra credits the intake quoted (refunded automatically if the finish cannot apply it); "no", or omitted, for the classic 4K 60 fps finish.
duration_sYesLength in seconds, as the user said or answered it (kleo_adapt_prompt asks when the request does not say). Required: Kleo never picks a length for the user.
referencesNoThe user's reference pictures: the handles (kref_…) kleo_adapt_prompt returned, or the token of a kleo_upload_link link they uploaded through. Kleo draws the characters from them.
storyboardNoOptional but recommended: the storyboard you wrote following kleo_storyboard_guide (a Keou project object without id, script_file, music_quiet or image scenes). IT MUST INCLUDE THE "direction" BLOCK the guide asks for first — a storyboard without one is refused, because the direction is what keeps a character the same person across shots and gives every scene the colour of its section. Its format and language must equal the ones you pass here, and its voice must belong to that language. When omitted entirely, Kleo plans the whole storyboard, direction included, from the prompt. Checked before anything is charged; on error the tool lists the problems so you can fix them and call again.
correctionsNoThe user's corrections after you read back what Kleo understood, IN THEIR OWN WORDS ("add my dog Pepe with a red collar", "she has red hair, not blonde"). The prompt stays their first request, unchanged; a spec item added by a correction quotes these words. Omit it when they simply said yes.
notify_emailNoOptional: email the download links when the render finishes.

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), it discloses the credit cost model, the 25–35 minute render time, background GPU execution, the fact that nothing is charged on error, and that credits are spent irreversibly once started. This is exactly the behavioral context the annotations cannot convey.

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

Conciseness2/5

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

It is a single ~370-word run-on paragraph with no structural breaks, and the animatic pricing ('5 credits up to 20 seconds, 10 up to 60 seconds') is stated twice verbatim. The purpose statement is buried mid-paragraph rather than front-loaded, hurting scannability.

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 20-parameter, nested-object, no-output-schema tool, the description covers preconditions, cost, timing, error semantics, the returned job_id/eta_min/credits, and the next step — everything an agent needs to call it correctly.

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%, so the schema already documents all 20 parameters in detail (voice ids, spec/treatment structure, storyboard requirements). The description largely restates contract facts already in the schema descriptions, hitting the baseline of 3 rather than adding substantial new field-level meaning.

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?

Despite a procedural opening, the description states a specific verb and resource — it 'starts rendering' the FILM or the ANIMATIC of a storyboard — and distinguishes the two products and their pricing/eligibility clearly. An agent can tell this apart from kleo_adapt_prompt and kleo_get_job 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 Guidelines5/5

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

It gives explicit preconditions ('Do not call this until the user has said, in their own words, what the video should be about'), handling for short-but-clear vs. subject-missing requests, and routes follow-up to kleo_get_job. Alternatives and when-not-to-call are both spelled out.

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

kleo_generate_thumbnailGenerate thumbnails (coming soon)AInspect

Not available yet in this beta: every finished video already comes with a thumbnail (see kleo_get_result). Calling this only records the request and returns a notice; do not promise extra thumbnails to the user.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idNoA finished video to take frames from.
promptNoOr describe the thumbnail you want.

TDQS

A4.7/5.0
Behavior5/5

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

Although annotations include openWorldHint and no destructive hint, the description reveals the critical behavioral truth: this is a no-op placeholder that only records the request and returns a notice. This goes well beyond what the annotations convey and prevents false expectations.

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 compact sentences, with the most important caveat ('Not available yet') front-loaded. Every sentence contributes essential guidance and there is no filler.

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 beta stub with two optional parameters< no output schema, and clear annotations, the description fully covers behavior, expectations, and the correct alternative. An agent has enough context to avoid misleading the user.

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?

The schema already fully documents both parameters with 100% coverageikuha, so the description need not repeat them. It indirectly implies the parameters will not produce a thumbnail, but it does not add per-parameter details beyond the schema.

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?

The first sentence immediately states this tool is unavailable and that finished videos already have thumbnails via kleo_get_result. The description also clarifies that calling it only records the request and returns a notice, so an agent understands this is a stub rather than the generation tool its title implies.

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?

It explicitly warns not to promise extra thumbnails and directs users to kleo_get_result for the existing thumbnail. This gives clear when-to-use and when-not-to-use guidance, plus a named alternative sibling.

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

kleo_get_jobCheck progressA
Read-onlyIdempotent
Inspect

Step 4. Progress of a video: state (queued, starting, rendering, finishing, done, failed, cancelled), what it is doing now, percent done and minutes left (eta_min). Use it for a one-off status check; to wait until the video is ready use kleo_wait_for_video instead. When the state is done, call kleo_get_result. Without a job_id it lists the account's recent videos.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idNoThe video number returned by kleo_create_video (for example gt_ab12cd34). Omit to list recent videos.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds useful behavioral context beyond annotations: the exact state values, the fact that it reports current activity and ETA, and the special case of listing recent videos when job_id is omitted. It does not detail potential error conditions, but for a read-only query tool this is sufficient.

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?

The description is dense but efficient, front-loading the core purpose and output fields. The opening 'Step 4.' is a minor noise element that references a workflow step but does not add actionable information; otherwise every sentence earns its place.

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 simple tool with one optional parameter and no output schema, the description adequately covers what the agent needs: state values, progress details, the alternative tool for waiting, and the next step (kleo_get_result). It omits edge cases like error handling, but these are not critical for a read-only status check.

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?

The schema description for job_id already includes the 'Omit to list recent videos' behavior, so the tool description adds no new semantics beyond what the schema provides. With schema coverage at 100%, the description correctly relies on the schema and does not need to repeat or expand parameter details.

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?

The description clearly states the tool's purpose: checking the progress of a video, enumerating the specific state values and output fields (percent done, eta_min). It distinguishes itself from siblings by name (kleo_wait_for_video and kleo_get_result) and explicitly describes the alternate behavior when no job_id is provided (listing recent videos).

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?

Usage is explicitly scoped: 'Use it for a one-off status check; to wait until the video is ready use kleo_wait_for_video instead. When the state is done, call kleo_get_result.' It also clarifies the optional job_id behavior. This leaves no ambiguity about when to select this tool over alternatives.

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

kleo_get_resultGet download linksA
Read-onlyIdempotent
Inspect

Step 5. Download links for a finished video (film or animatic): the MP4, the thumbnail and the subtitles as an .srt file (burned-in subtitles and the music track, when the user asked for them, are inside the MP4), and, when the pictures were checked against the user's request, one line saying how many of the things they asked for the pictures show and which they miss.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYesThe video number returned by kleo_create_video.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by detailing exactly what the download links contain (including burned-in subtitles and music track) and the conditional line about picture checks. This goes beyond the structured annotations.

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?

The description is a single packed sentence starting with 'Step 5' and includes all necessary details without redundancy. It is slightly dense and could be split for readability, but every clause serves a purpose.

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 one-parameter read-only tool with no output schema, the description adequately explains what the result contains (MP4, thumbnail, .srt file, optional check line) and the condition for the check line. It doesn't cover error cases for unfinished jobs, but the 'finished video' qualifier hints at the precondition.

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?

The input schema already fully describes job_id as 'The video number returned by kleo_create_video' with 100% coverage. The description adds only that the video must be finished, which is contextual rather than new parameter semantics, so the baseline 3 is appropriate.

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?

The description clearly states the tool retrieves download links for a finished video and enumerates the deliverables (MP4, thumbnail, subtitles). The 'Step 5' prefix positions it within a workflow, distinguishing it from siblings like kleo_get_job (status) or kleo_wait_for_video (waiting).

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?

The condition 'for a finished video' and 'Step 5' imply the appropriate time to call, and the list of returned files helps an agent understand what to expect. However, it does not explicitly mention alternative tools or state when not to use it, leaving some inference to the agent.

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

kleo_list_templatesList the template and the two productsB
Read-onlyIdempotent
Inspect

Lists Kleo's one template, film (realistic or animation look, 16:9 or 9:16, 15-300 s), and its two products: the film (every shot a generated clip — moving footage by ByteDance Seedance 2.5 from a frame drawn by Google Nano Banana Pro — priced by length, for accounts that have bought a credit pack) and the animatic (the same drawn frames with camera moves, 5 credits up to 20 seconds, 10 up to 60 seconds, every account). Music and burned-in subtitles are options in both: the user is always asked and gets them only when they say yes.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so safety is covered. The description adds real domain context absent from structured fields — credit costs (5/10 credits), duration limits, account eligibility for the credit-pack-only film product, and that music/subtitles are opt-in. However, it never describes the tool's own behavior, e.g. whether results are static/cached or what a caller gets back.

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?

The pithy purpose is front-loaded, which is good, but it is followed by one sprawling multi-clause sentence dense with pipeline internals (Seedance 2.5, Nano Banana Pro) that a caller selecting the tool does not need. Several details feel like marketing copy rather than decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining what comes back, and it does convey the substance of the two products and their options. But it never states the response shape (a list of what — IDs, names, descriptors), which is the one thing an agent needs before invoking a listing tool.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The schema is empty and fully consistent with a no-argument listing tool.

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 clause states a concrete verb and resource ('Lists Kleo's one template... and its two products'), so the agent knows this is a catalogue-enumeration tool. No sibling (kleo_create_video, kleo_storyboard_guide, kleo_account, etc.) overlaps with listing, so differentiation is implicit rather than stated. The rest of the sentence drifts into product details rather than sharpening the purpose.

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

Usage Guidelines2/5

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

There is no explicit when-to-use statement, no mention of a prerequisite step preceding kleo_create_video, and no named alternative. The reader can infer it is a discovery step, but nothing tells the agent when to call it versus going straight to creation or the storyboard guide.

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

kleo_redeemRedeem a launch codeA
Idempotent
Inspect

Redeems a Kleo launch code the user gives you (PRODUCTHUNT, HN, REDDIT, X, TIKTOK, or another code Kleo published). One code per account: it adds the credits of a 15-second film and opens ONE free film of up to 15 seconds, even on an account that has never bought a pack. Call it only with a code the user typed, never one you guess. Then offer to make that film (kleo_adapt_prompt with a length of 15 seconds and product "film").

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe code exactly as the user gave it (case does not matter).

TDQS

A4.5/5.0
Behavior4/5

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

Adds substance beyond the annotations: one code per account, credit grant equivalent to a 15-second film, and a free film even for accounts that never bought a pack. It does not say what happens on an invalid or already-redeemed code, but the effects are otherwise well disclosed.

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 tight sentences, front-loaded with what the tool does before the operational constraints and the follow-up action. Dense but nearly every clause carries actionable information.

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 single-parameter mutation with no output schema, the description covers effect (credits + free film), idempotency context, and the next step. The only omission is error/duplicate handling, which is minor.

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, and the description adds a genuine constraint: the code must come from the user, never be guessed. The 'case does not matter' detail is left to the schema, which already documents it.

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 and resource ('Redeems a Kleo launch code') and enumerates the recognizable examples (PRODUCTHUNT, HN, REDDIT, X, TIKTOK). This is clearly distinguishable from sibling tools like kleo_account or kleo_create_video.

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 negative constraint ('Call it only with a code the user typed, never one you guess') and an explicit follow-up route ('offer to make that film (kleo_adapt_prompt with a length of 15 seconds and product "film")'), naming sibling tools and parameters to use next.

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

kleo_storyboard_guideStoryboard guide (write your own video)A
Read-onlyIdempotent
Inspect

Step 2 (recommended). Returns how to write a storyboard Kleo renders, in the order it should be written: first the DIRECTION of the film (subject, goal, audience, tone, the facts from the request that the narration must still say, the world it is drawn in, what must never appear, and one accent colour per section), then the scene and shot shapes, the limits Kleo enforces before anything is billed, and one worked example. Kleo has two looks, realistic and animation; in both every shot starts as one frame drawn in that look — in the film it becomes a generated clip, in the animatic the camera moves over the frame — so the same storyboard serves both products. Call it once per conversation, before kleo_create_video. Without a storyboard Kleo plans a more generic one from the prompt.

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNoThe look: "realistic" (filmed) or "animation" (a 2D animated film); in both every shot is generated footage from its own frame, under the narration. Realistic when omitted.
formatNoThe frame the video will be in. The explainer authors its drawings in the frame's own pixels, so its guide prints different coordinates for 9:16 and 16:9; the template's own format is used when this is omitted.
productNoThe product the user chose (film or animatic): a film's pictures become paid clips, and the guide says how many a line can carry. Film when omitted.
templateNoOptional: Kleo uses the only active workflow, film.
duration_sNoTarget length in seconds, if the user chose one.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark it read-only and idempotent, but the description adds valuable behavioral context: it returns guides, mentions 'limits Kleo enforces before anything is billed,' and clarifies that the same storyboard serves both film and animatic. This goes beyond the structured annotations.

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?

The description is dense but every sentence earns its place. It front-loads the action ('Step 2 (recommended). Returns how to write a storyboard...') and then efficiently covers ordering, product behavior, invocation timing, and fallback behavior without redundancy.

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?

Despite having no output schema, the description comprehensively explains what the returned guide contains, how it should be used, when to call it, and what happens if it isn't called. Combined with the rich input schema and annotations, nothing essential is missing for an agent to invoke it correctly.

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 schema already gives detailed descriptions for style, format, product, template, and duration_s. The description adds high-level context about the two looks and shared storyboard, but does not materially extend parameter-level meaning beyond the schema.

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?

The description clearly states the tool's purpose: it returns how to write a storyboard Kleo renders, in the order it should be written. It distinguishes itself from siblings by specifying it is Step 2 and should be called before kleo_create_video.

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?

The description gives explicit usage context: 'Call it once per conversation, before kleo_create_video.' It also explains the consequence of not using it: 'Without a storyboard Kleo plans a more generic one from the prompt,' which tells the agent when this tool is needed.

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

kleo_wait_for_videoWait for the video (keeps the chat working until it is ready)A
Read-onlyIdempotent
Inspect

Step 4b. Waits up to max_wait_s seconds (default 50) for a video and returns either the download links (when done) or its progress. THIS IS HOW YOU DELIVER A VIDEO WITHOUT ASKING THE USER TO COME BACK: after kleo_create_video, call kleo_wait_for_video again and again, one call after the other, until it returns the links (a Short usually needs 15–25 calls, a long video more). Do not stop after a few calls and do not ask the user whether to continue; only stop if the user asks you to, or if the result says the video failed or was cancelled. Say once that the render is running and how long it should take, then keep calling silently and finally hand over the links.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idNoThe video number from kleo_create_video. Omit to wait for your most recent video.
max_wait_sNoHow long this call may wait before reporting progress, in seconds. Leave it empty: Kleo picks a safe value for your client (45 s for ChatGPT and Grok, 170 s for Claude, 5 minutes for OpenCode).

TDQS

A4.9/5.0
Behavior5/5

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

The description goes beyond annotations by disclosing the polling nature of the tool, the expected number of calls (15–25 for Shorts), and the interaction pattern (silent repeated calls). It also clarifies when to stop, which is critical behavioral context that annotations do not cover.

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?

The description is dense but efficient, front-loading the core purpose and then providing essential usage loop instructions. Every sentence contributes actionable guidance, and the structure flows logically from what to do to how to do it.

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?

The description is complete for an agent: it covers when to use, how to call repeatedly, how to handle progress, when to stop, and what to expect (links or progress). It also mentions failure/cancellation handling, making it self-contained for correct usage.

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?

While schema coverage is 100%, the description adds practical advice on the max_wait_s parameter (recommending to leave it empty and providing client-specific defaults). This adds meaning beyond the schema, though job_id is already well-described.

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?

The description clearly states the tool's function: it waits for a video to be ready and returns download links or progress. It distinguishes itself from siblings by explicitly tying it to the creation workflow and positioning it as the polling mechanism for delivering videos.

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?

The description provides explicit usage guidance: it instructs the agent to call this tool repeatedly after kleo_create_video until links are returned, and to avoid stopping or asking the user unless the user requests it or failure/cancellation occurs. This is a clear 'when and how to use' directive.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updates
    • Changedkleo_adapt_prompt1 field changed
      • changedInput schema / properties / product / description
        Previous value: -"The user's answer to the question film or animatic, which the tool asks with this account's prices: \"film\" (every shot a generated clip, for accounts that have bought a pack) or \"animatic\" (the drawn frames with camera moves, 5 credits flat, up to 60 seconds). Never a guess."New value: +"The user's answer to the question film or animatic, which the tool asks with this account's prices: \"film\" (every shot a generated clip, for accounts that have bought a pack) or \"animatic\" (the drawn frames with camera moves, 5 credits up to 20 seconds, 10 up to 60 seconds). Never a guess."
    • Changedkleo_create_video1 field changed
      • changedInput schema / properties / product / description
        Previous value: -"The product the user chose in the intake (kleo_adapt_prompt asks it, with the prices): pass it. What to make from the storyboard: \"film\" (default; every shot a generated clip, priced by length, for accounts that have bought a credit pack) or \"animatic\" (the same drawn frames with the camera moving over each one, the same narrator and layer, 4K 60 fps, no generated clip; 5 credits flat, up to 60 seconds, every account). Say which one you are ordering to the user before you call."New value: +"The product the user chose in the intake (kleo_adapt_prompt asks it, with the prices): pass it. What to make from the storyboard: \"film\" (default; every shot a generated clip, priced by length, for accounts that have bought a credit pack) or \"animatic\" (the same drawn frames with the camera moving over each one, the same narrator and layer, 4K 60 fps, no generated clip; 5 credits up to 20 seconds, 10 up to 60 seconds, every account). Say which one you are ordering to the user before you call."
    • Addedkleo_redeem
  2. 1 tool update
    • Changedkleo_create_video1 field changed
      • changedInput schema / properties / music / description
        Previous value: -"The user's answer about music, exactly as you passed it to kleo_adapt_prompt: \"no\" (or null) for none; \"yes\" or the kind they want for an instrumental track under the narration (the treatment's \"music\" brief is used when it has one). Kleo orders the track from kie.ai and ducks it under the voice."New value: +"The user's answer about music, exactly as you passed it to kleo_adapt_prompt: \"no\" (or null) for none; \"yes\" or the kind they want for an instrumental track under the narration (the treatment's \"music\" brief is used when it has one). Kleo has the track composed by Suno and ducks it under the voice."
  3. 2 tool updates
    • Changedkleo_adapt_prompt1 field changed
      • addedInput schema / properties / ai_upscale
        Added value: +{
+  "description": "The user's answer to the AI upscale question, in their words (\"yes\" / \"no\"): asked for a film only, with its price in extra credits. Only a clear yes buys it; \"no\", \"whatever\" or no answer means the classic 4K 60 fps finish. Never a guess.",
+  "maxLength": 80,
+  "type": "string"
+}
    • Changedkleo_create_video1 field changed
      • addedInput schema / properties / ai_upscale
        Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "maxLength": 80,
+      "type": "string"
+    }
+  ],
+  "description": "The user's answer to the AI upscale question kleo_adapt_prompt asked (film only): \"yes\" for Real-ESRGAN + RIFE on every shot, at the extra credits the intake quoted (refunded automatically if the finish cannot apply it); \"no\", or omitted, for the classic 4K 60 fps finish."
+}
  4. 3 tool updates
    • Changedkleo_adapt_prompt4 fields changed
      • changedInput schema / properties / language / description
        Previous value: -"Language of the narration; detected from the request when omitted."New value: +"The user's answer to the question about the narration's language, in their words (\"en\", \"English\", \"italiano\"…): Kleo narrates in English or Italian, and \"whatever\" / \"no preference\" means English. Asked every time the request does not say it: pass their answer, never a guess, and never the language they write to you in."
      • removedInput schema / properties / language / enum
        Removed value: -[
-  "en",
-  "it"
-]
      • addedInput schema / properties / language / maxLength
        Added value: +40
      • addedInput schema / properties / product
        Added value: +{
+  "description": "The user's answer to the question film or animatic, which the tool asks with this account's prices: \"film\" (every shot a generated clip, for accounts that have bought a pack) or \"animatic\" (the drawn frames with camera moves, 5 credits flat, up to 60 seconds). Never a guess.",
+  "enum": [
+    "film",
+    "animatic"
+  ],
+  "type": "string"
+}
    • Changedkleo_create_video2 fields changed
      • changedInput schema / properties / language / description
        Previous value: -"Voice and caption language. A storyboard you pass must declare this same language."New value: +"Voice and caption language: the narration language the user chose, as kleo_adapt_prompt's \"language\" returned it (the intake asks it; never the language of the chat). A storyboard you pass must declare this same language."
      • changedInput schema / properties / product / description
        Previous value: -"What to make from the storyboard: \"film\" (default; every shot a generated clip, priced by length, for accounts that have bought a credit pack) or \"animatic\" (the same drawn frames with the camera moving over each one, the same narrator and layer, 4K 60 fps, no generated clip; 5 credits flat, up to 60 seconds, every account). Say which one you are ordering to the user before you call."New value: +"The product the user chose in the intake (kleo_adapt_prompt asks it, with the prices): pass it. What to make from the storyboard: \"film\" (default; every shot a generated clip, priced by length, for accounts that have bought a credit pack) or \"animatic\" (the same drawn frames with the camera moving over each one, the same narrator and layer, 4K 60 fps, no generated clip; 5 credits flat, up to 60 seconds, every account). Say which one you are ordering to the user before you call."
    • Changedkleo_storyboard_guide1 field changed
      • addedInput schema / properties / product
        Added value: +{
+  "description": "The product the user chose (film or animatic): a film's pictures become paid clips, and the guide says how many a line can carry. Film when omitted.",
+  "enum": [
+    "film",
+    "animatic"
+  ],
+  "type": "string"
+}
  5. 3 tool updates
    • Changedkleo_adapt_prompt2 fields changed
      • changedInput schema / properties / author / description
        Previous value: -"Who writes the treatment. \"assistant\" (default): Kleo hands YOU the producer's method and you write it — you are a far stronger writer than Kleo's own planning model, and it costs nothing. \"server\": Kleo's model writes it (use only if you cannot write JSON yourself)."New value: +"Who writes the spec and the treatment. \"assistant\" (default): Kleo hands YOU the two methods and you write them — you are a far stronger writer than Kleo's own planning model, and it costs nothing. \"server\": Kleo's model writes them (use only if you cannot write JSON yourself)."
      • addedInput schema / properties / references
        Added value: +{
+  "description": "The pictures the user gave for this film, each with ONE of: url (a public https link), upload (the token of a kleo_upload_link link they uploaded through), handle (kref_… returned earlier); plus role and name when the user said what it shows. Kleo draws the characters, objects and places FROM these pictures.",
+  "items": {
+    "properties": {
+      "handle": {
+        "description": "A handle (kref_…) this tool or the upload page returned earlier.",
+        "pattern": "^kref_[0-9a-f]{8}$",
+        "type": "string"
+      },
+      "name": {
+        "description": "The character's name, when the picture is of a character (\"Mara\", \"my dog Pepe\").",
+        "maxLength": 60,
+        "type": "string"
+      },
+      "note": {
+        "description": "What the user said about the picture, in their words.",
+        "maxLength": 300,
+        "type": "string"
+      },
+      "role": {
+        "description": "What the picture is for: character (draw this person/animal/creature), object, place, or style (imitate the look).",
+        "enum": [
+          "character",
+          "object",
+          "place",
+          "style"
+        ],
+        "type": "string"
+      },
+      "upload": {
+        "description": "The token of a kleo_upload_link link the user uploaded pictures through: every picture uploaded there is taken.",
+        "maxLength": 400,
+        "type": "string"
+      },
+      "url": {
+        "description": "A public https:// link to the picture (PNG, JPEG or WebP, up to 12 MB).",
+        "maxLength": 2000,
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "maxItems": 8,
+  "type": "array"
+}
    • Changedkleo_create_video6 fields changed
      • addedInput schema / properties / audience
        Added value: +{
+  "description": "Who the film is for, as the user said it.",
+  "maxLength": 160,
+  "type": "string"
+}
      • addedInput schema / properties / corrections
        Added value: +{
+  "description": "The user's corrections after you read back what Kleo understood, IN THEIR OWN WORDS (\"add my dog Pepe with a red collar\", \"she has red hair, not blonde\"). The prompt stays their first request, unchanged; a spec item added by a correction quotes these words. Omit it when they simply said yes.",
+  "maxLength": 1000,
+  "type": "string"
+}
      • addedInput schema / properties / must_keep
        Added value: +{
+  "description": "The user's answer to \"what must appear, or must not\", as passed to kleo_adapt_prompt.",
+  "maxLength": 400,
+  "type": "string"
+}
      • addedInput schema / properties / references
        Added value: +{
+  "description": "The user's reference pictures: the handles (kref_…) kleo_adapt_prompt returned, or the token of a kleo_upload_link link they uploaded through. Kleo draws the characters from them.",
+  "items": {
+    "maxLength": 400,
+    "type": "string"
+  },
+  "maxItems": 8,
+  "type": "array"
+}
      • addedInput schema / properties / spec
        Added value: +{
+  "additionalProperties": {},
+  "description": "The SPEC you wrote under kleo_adapt_prompt's spec method (or the one it returned), corrected as the user asked: {v:1, mode, summary, cast, items, refs, open, narration, script}. Every item's \"quote\" must be the user's own words from the prompt, from their must_keep/audience/tone answers, or from their \"corrections\" after the read-back (pass those too). Checked before anything is charged; the film is planned under it and every picture is checked against it.",
+  "properties": {},
+  "type": "object"
+}
      • addedInput schema / properties / tone
        Added value: +{
+  "description": "The tone the user asked for.",
+  "maxLength": 160,
+  "type": "string"
+}
    • Addedkleo_upload_link
  6. 10 tool updates
    • First observedkleo_account
    • First observedkleo_adapt_prompt
    • First observedkleo_cancel_job
    • First observedkleo_create_video
    • First observedkleo_generate_thumbnail
    • First observedkleo_get_job
    • First observedkleo_get_result
    • First observedkleo_list_templates
    • First observedkleo_storyboard_guide
    • First observedkleo_wait_for_video

Related MCP Connectors

Related MCP Servers

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