AutoShort MCP best practices

Short, practical rules for making AI-generated shorts through an assistant connected to AutoShort. Each one says what to do, why, and what it rests on: our own data, a study of public Shorts, how the tools behave, or just a working rule.

To connect your assistant first, see the connect page. For text you can paste, see the free prompts and the recipes.

Before you render: a checklist

Everything up to step 5 is free. A standard short of up to 90 seconds costs 40 credits with the default voice, charged at step 6.

  1. Agree the script in chat. Ask the assistant to write the script scene by scene. Check that scene 1 is 9 words or fewer and that its picture is already in motion.
  2. Create a free draft. Ask for autoshort_draft_video with scenes[]. This stores your script word for word and charges nothing.
  3. Read the draft and its warnings. Ask for autoshort_get_draft and read every scene, the estimated length and each warning.
  4. Fix scenes for free. Ask for autoshort_update_draft to change narration, pictures or length. Read the updated draft again.
  5. Get the price. Ask for autoshort_estimate_cost for the draft. Check the credits, your balance and your daily cap.
  6. Say yes once. Tell the assistant to call autoshort_render_draft once for this draft, nothing else.
  7. Wait and check. Ask the assistant to poll autoshort_get_video until COMPLETED or FAILED. If it failed, look for the Refund line in your credit history.

The points

Write the hook in 9 words or fewer

Working rule, not a measured result
Do
Make the first spoken sentence the content itself, at most 9 words. Skip scene-setting openers such as "In a", "Once upon" or "It was".
Why
A viewer decides in the first seconds. A short first line gets to the point before they scroll.
What it rests on
In our own hook check of 8 finished videos (2026-10-26), 3 had a first sentence of 9 words or fewer and 5 were longer. We have no retention data yet that shows the short ones hold viewers better, so this is a working rule, not a result.
Try the prompt
Do
Write the visual of scene 1 as an event under way (a paw already knocking a cup, a hand already turning a page), not a pose or a wide establishing shot.
Why
It gives the first second something to look at, and it is the one first-frame pattern that stood out in public data.
What it rests on
In 999 matched pairs of public Shorts (not ours), a first frame showing an event already under way was 5.1 percentage points more common among Shorts that beat their own channel average (95% interval 1.4 to 8.9). Small effect, observational, not a prediction.
Try the prompt
Do
Tell the assistant: show me the price first and wait for my yes before any paid step. It should call autoshort_estimate_cost, read you the credits, and wait.
Why
A render is charged the moment autoshort_render_draft runs. Estimating is free and takes one call.
What it rests on
The autoshort_render_draft description says to call it only after the user has seen the draft and said yes, and that it charges before any rendering work. autoshort_estimate_cost prices a paid call without creating or charging anything.
Try the prompt

Make one episode, watch it, then plan the next

Working rule, not a measured result
Do
Render episode 1 only. Watch it, note what drifted or fell flat, and change episode 2 before you draft it.
Why
Everything you learn from one episode is free to apply to the next. A batch locks in the same mistake several times.
What it rests on
We have no controlled comparison of batches against single episodes. This is advice from how we made our own series, not a measured result.
Try the prompt
Do
Write the character, the episode list and each cliffhanger in the conversation. If you want to store it, create a series with startPaused set to true and the plan as its brief, and copy the plan to your own notes too.
Why
A plan you can read and change costs nothing. Starting a series costs credits every time the scheduler makes a video.
What it rests on
autoshort_create_series is free and its startPaused option creates it without generating. A running series writes each script itself from the brief, so it does not follow your episode scripts line by line. The planning tools for whole seasons are not among the tools every account has. In a separate study of public Shorts, when a Short was an outlier (at least 5 times its channel median), the next one was too 28% of the time against 8% otherwise (observational).
Try the prompt
Do
Have the assistant call autoshort_get_draft and read you every scene and every warning. Fix scenes with autoshort_update_draft. Then estimate and decide.
Why
Narration is read exactly as written, so every typo, wrong fact and length problem is voiced. Drafts and edits are free; a render is not.
What it rests on
The draft tool returns the scenes, an estimated length, estimated credits and warnings[]; a mismatch between the requested duration and the narration is reported there. English narration runs at about 2.4 words per second, so 70 words is roughly 30 seconds.
Try the prompt
Do
Write one sentence that describes the character (species, colour, size, one marking, one accessory) and paste it unchanged into the visual of every scene. Put one character in each picture. Do not promise yourself a perfect match.
Why
Each image is generated on its own. A repeated sentence narrows what the generator draws; two subjects in one description invites the wrong animal.
What it rests on
In our own animal series (a capybara) made with our character-sheet tool, the same animal appeared in every shot of episode 1, but the style drifted between realistic fur and a more cartoon look, and the size and ear colour varied a little. In an earlier test a mascot description naming an orangutan and a panda produced two pandas. The character-sheet tool is not among the tools every account has, so with the standard draft tools the sentence is all you have.
Try the prompt
Do
Ask the assistant to read autoshort_get_limits at the start. Set a daily cap you are comfortable with using autoshort_set_limits. Approve one render at a time, and let the assistant reuse the same idempotencyKey when it retries.
Why
A cap stops a looping assistant from burning your balance. An idempotency key makes a retry return the first result instead of charging again.
What it rests on
Each connection has a daily agent spending cap; lowering it takes effect at once, raising it needs you to approve a link. autoshort_render_draft is retry-safe (a repeated call returns the first submission and charges nothing) and a draft can be rendered only once. autoshort_cancel_video refunds a video that has not started rendering.
Default cap
Each connection can commit at most 500 credits per UTC day unless you change it.
Try the prompt
Do
Ask the assistant to poll autoshort_get_video until the status is COMPLETED or FAILED. If it is FAILED, open Dashboard, Credits and look for a Refund line. If the answer carries a blockedReason such as INSUFFICIENT_CREDITS, the video is waiting for credits: stop polling, top up, then continue.
Why
Failed renders are meant to be returned automatically. Looking at the ledger is the quickest way to know your balance is right.
What it rests on
The refund policy says credits for a failed render are returned automatically. On 2026-10-28 we checked this on production with a synthetic failed video on our QA account: one refund was granted, and a second pass granted nothing more. We could not force a real failed render without spending, so that check is a test of the refund job, not a sample of real failures.
Try the prompt

Failed renders and refunds: the real rules

  • If a video you were charged for fails to render, the credits it used are returned to your balance automatically. The return shows as a Refund line in your credit history.
  • A video that finishes and is delivered is not a failed render, so its credits are not returned. When an AI-motion clip falls back to a still image, only the motion credits for that clip are returned.
  • A background job looks for failed videos that still hold a charge and returns them. It skips anything older than 7 days and anything that failed in the last 10 minutes.
  • Only a charge comes back. A render that was never charged has nothing to return.
  • You can cancel a video that has not started rendering with autoshort_cancel_video; it is refunded through the credit ledger. Once rendering has started it cannot be cancelled.

Known gaps

  • Our audit on 2026-10-28 found paths where a failed video could keep its charge: a failed child of a bulk batch, videos swept as permanently stuck, a refund that failed once and was never retried, and a song request that failed after the charge. A fix for these was merged the same day.
  • The single slideshow set path has no durable record, so a crash in that one path can still strand a charge. We list it as not fixed.
  • The 7-day window means a failed video older than that is not returned automatically. Write to support@autoshort.org and we will look at it.

The wording that binds us is on the refund policy. Prices are on what each action costs.

Questions

Will my character look identical in every scene?

No. Every image is generated separately. Repeating the same one-sentence description and keeping one subject per picture helps, but in our own animal series the style and small details still drifted between shots.

How do I stop my assistant from spending too many credits?

Ask it to read autoshort_get_limits, lower the daily cap with autoshort_set_limits, and wait for your yes before each render. Raising the cap needs your approval on a link that you open yourself.

Is a failed render refunded?

Yes, automatically, and it shows as a Refund line in your credit history. If you do not see one, email support@autoshort.org. The refund policy page has the full wording.

How long should a script be for a 30-second short?

About 70 words. English narration runs at about 2.4 words per second and the video lasts as long as the narration takes to read. The draft warns you when your narration does not fit the length you asked for.

Keep going