Skip to main content
Glama

Plan an AI short

ai_short_draft
Read-only

Free. Plans a finished AI short (several AI video shots, voice or dialogue, music, captions) from an idea. Nothing is made or charged. Show the user the reply, the shots and quote.render_cents, refine with ai_short_revise, then make it with ai_short_create.

Args: brief: the idea in the user's words, 1-4000 chars, any language. length: target seconds (3-60; longer is planned as 60), only when the user named one. quality: fast (cheapest) | pro | ultra (best); the director picks when omitted (the desktop tool defaults to pro). aspect: 9:16 (default) | 16:9 | 1:1. source: a source from remix_read_source / read_article: makes an ORIGINAL short from it. angle: with source: similar (default) | my_niche | part2 | rewrite. attachment_ids: staged image ids (up to 8). persona_id: a saved persona whose photos are staged for you.

Returns: {ok, reply, plan|null, changed, chips:[{label, message?, action?}], notes, quote?:{render_cents, items, blockers, fits}, history}. A chip with action top_up or sign_in means the balance or sign-in needs the user. Pass history back to ai_short_revise.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brief": "<brief>"
    },
    "name": "ai_short_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
angleNo
briefYes
aspectNo
lengthNo
sourceNoA `source` from read_article / remix_read_source.
qualityNo
persona_idNo
attachment_idsNoStaged image ids (up to 8) the short may show or use as references.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and the description reinforces this with "Nothing is made or charged" rather than contradicting it. Beyond that it discloses the cost preview field (quote.render_cents), the blocker semantics in quote, and that a chip with action top_up or sign_in signals a balance or sign-in problem needing the user, plus the need to pass `history` back to ai_short_revise.

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 front-loaded with the single most decision-relevant fact (free, plan-only) followed by the workflow, then structured Args and Returns blocks. The density is justified by eight parameters and a documented return shape; no sentence is 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?

There is no output schema, so the inline Returns block carries the full burden: it lists the object fields, explains the plan|null case, and explains the chips and quote semantics. Combined with per-parameter docs and the sibling routing, an agent has everything needed to call this and hand off to revise or create.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%, but the Args section compensates by documenting all eight parameters with meaning beyond the schema: length is clamped ("longer is planned as 60"), length should only be set when the user named one, quality is director-chosen when omitted with the desktop default called out, and defaults for aspect and angle are given. This is exactly the compensation the low schema coverage requires.

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 a specific verb and artifact: "Plans a finished AI short (several AI video shots, voice or dialogue, music, captions) from an idea," and immediately states the boundary "Nothing is made or charged," which separates it from ai_short_create. An agent can distinguish planning from creation and revision without opening a sibling 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 prescribes the full workflow explicitly: "Show the user the reply, the shots and quote.render_cents, refine with ai_short_revise, then make it with ai_short_create." That names both the downstream alternatives and the sequence that selects them, which is stronger than a generic when-to-use sentence.

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