Check which SuperCMO media-generation keys are configured and which capabilities (image / video / audio) are ready — the setup doctor. Call this FIRST when a user is setting up SuperCMO, asks which keys they need, or a generation failed with 'no_provider_configured'. Returns each vendor key (set/missing, what it enables, where to get it), managed-key state, and per-capability readiness. Set check=true for a FREE key-validity probe where one exists (never a paid generation). Reports only key NAMES and set/missing — never key values.

For a user's image request, load the generating-images skill BEFORE calling this — it picks the right model and builds the prompt (this tool does neither, and calling it raw gives weak, inconsistent results). Generate one or many still images from text prompts, optionally guided by reference images (a product photo, a character, a style or composition to follow). Pass requests: ONE object per image (wrap even a single image — { requests: [ { prompt } ] }). Generate a batch of DIFFERENT images in a SINGLE call by adding more request objects (up to 10), each with its own prompt/model/aspect_ratio/resolution/reference_images; a single approval covers the whole batch. Each result carries a hosted image URL plus a local file path, or a structured error with a hint. Use for graphics, mockups, product/marketing visuals, logos, concept art, or to render a product or character from a supplied reference. Images are polled for you; a heavy image (large model / 4k / big batch) that runs long returns {status:"pending", ...} (a job handle, not an error) — pass that exact handle to job_status to retrieve it, and never re-submit a pending image. Set dry_run=true to preview the exact requests and cost without generating (no credits spent).Each entry in results is one of three things: finished media; a {status:"pending", ...} job handle to rejoin with job_status; or a failure carrying ok: false and an error. A failed entry is terminal — report its error and never poll or re-submit it. Read every entry rather than the top-level counters alone.

List the available image-generation models (with strengths, price, the aspect ratios each accepts and how many reference images it takes), plus the valid aspect ratios and resolution tiers that image_generate accepts. Use when you need to choose a model and don't already have one in mind (e.g. an open-ended request), or to check the valid aspect_ratio / resolution values, or how many reference images a model will take, before calling image_generate — most of the time the model is the default or already specified. Pass an optional 'query' to filter models by use-case keyword (e.g. 'text', 'photorealistic', 'fast').

For a user's video request, load the generating-videos skill BEFORE calling this — it picks the right model and builds the motion prompt (this tool does neither, and calling it raw gives weak, generic clips). Generate one or many short video clips from text prompts, optionally guided by a start (and end) frame or by reference images, videos, or audio. Pass requests: ONE object per clip (wrap even a single clip — { requests: [ { prompt } ] }); add more objects (up to 10) to batch DIFFERENT clips in one call, and repeat an object for variations of one prompt — a single approval covers the batch. Models differ in the aspect ratios, durations, resolutions, and media they accept — call list_video_models to check. Video generation is long-running: each clip is submitted and polled for you. A clip that finishes in time returns a hosted video URL plus a local file path; a clip still generating returns {status:"pending", ...} (a job handle, NOT an error) — pass that exact handle to job_status to retrieve it, and never re-submit a pending clip. Set dry_run=true to preview the exact requests without generating (no credits spent).Each entry in results is one of three things: finished media; a {status:"pending", ...} job handle to rejoin with job_status; or a failure carrying ok: false and an error. A failed entry is terminal — report its error and never poll or re-submit it. Read every entry rather than the top-level counters alone.

List the available video-generation models with, for each, its full schema: modes (text / image / first-last-frame / reference), the aspect ratios, durations and resolutions it accepts, which media it takes (start/end frame and reference image/video/audio with max counts), whether it has native audio, plus strengths and price. This is the authoritative source for a model's exact ranges — call it when choosing a model for an open-ended request, or to check what a model accepts before setting aspect_ratio / duration / resolution / media. Pass an optional 'query' to filter by use-case keyword (e.g. 'cinematic', 'fast', 'audio').

For a user's voiceover request, load the generating-audio skill BEFORE calling this — it picks the right model and voice and prepares the script for reading aloud (this tool does none of that, and calling it raw gives a flat, mispronounced read). Turn written text into spoken audio: voiceovers, narration, ad reads, character lines, or any script read aloud. Pass requests: ONE object per clip (wrap even a single clip — { requests: [ { text } ] }); add more objects (up to 10) to generate DIFFERENT lines in one call — a single approval covers the batch. Each result carries the spoken audio plus a local file path, or a structured error with a hint. This generates speech and nothing else: no sound effects, music, or ambience, no re-voicing an existing recording, and no dubbing a video. If the user asks for one of those, say so plainly rather than substituting a different tool. Every request needs a voice — the voice_id of a row from list_voices. There is no default voice. Models differ in expressiveness, language coverage, speed, price, and per-request character limit — call list_audio_models to compare them. Set dry_run=true to preview the exact requests without generating (no credits spent).Each entry in results is one of three things: finished media; a {status:"pending", ...} job handle to rejoin with job_status; or a failure carrying ok: false and an error. A failed entry is terminal — report its error and never poll or re-submit it. Read every entry rather than the top-level counters alone.

List the available speech models — for each, its strengths, price, per-request character limit, language coverage, and the audio types it supports — plus the output formats audio_generate accepts. Every model works with every voice, so voices are a separate concern — use list_voices for those. This is the authoritative source for what a model accepts; call it when choosing a model for an open-ended request, or to check a value before setting it. Pass an optional 'query' to filter models by use-case keyword (e.g. 'expressive', 'long-form', 'fast').

Find a voice to speak with, and get the voice_id that audio_generate requires. Returns the voices saved in the active ElevenLabs account — the user's own on their key, or the shared SuperCMO set on a managed key — each with its gender, accent, age, use-case and a preview_url you can hand the user so they hear it before committing. Filter by what the brief actually demands (a stated gender or accent is not negotiable) and keep limit small: offer a few candidates with their previews rather than a long list. A voice missing the attribute you filtered on is kept rather than dropped, because a voice the user cloned themselves often carries no labels at all. If the account holds no voices the result says so — a newly created ElevenLabs account starts empty, and voices must be added in the ElevenLabs dashboard before anything can be spoken.

Extract structured data from a web page — a product listing (Amazon, Shopify, AliExpress, any store) or any URL — guided by a prompt and/or a JSON schema. Returns the requested fields (e.g. name, brand, price, description, specs) and any gallery image URLs as a compact JSON object, plus page metadata — not the page's full text. Use when you need specific data or image URLs from a page. Set dry_run=true to preview the exact request without spending.

Look at an image (a local file path or an image URL) and answer a question about it — returns text, not a new image. Use to read a product photo (category, materials, on-pack text, distinctive details), to judge whether a shot is product-only or shows a face, or to describe any image's content, layout, or text. Give a specific 'prompt' for a focused answer; omit it for a general description. Set dry_run=true to preview the request without spending.

Watch a video (a local file path or a video URL) and answer a question about it — returns text, not a new video. Use to read a supplied or reference clip before generating: its subject and setting, the key actions, the camera work and motion, the pacing, and the gist of any audio, so a new prompt can animate or match it instead of contradicting it. Give a specific 'prompt' for a focused answer; omit it for a general breakdown. Analyzes a clip inline, so a very large file may be rejected — trim or link a shorter clip if so. Set dry_run=true to preview the request without spending.

Join finished video clips into one file, in the order given, with a hard cut between each and each clip's audio kept — this assembles existing clips, it does not generate new video. Use it to build a video longer than a single model clip: generate the shots with video_generate, then stitch them. Do NOT use it for a single clip, or for a batch of clips meant to stay separate. Optionally lay a background-music track under the whole thing (pass music) or burn in subtitles from an SRT file (pass subtitles); clips of different sizes are scaled to a common frame. Returns the output file path with its duration, resolution, and size, or a structured error with a hint. Requires ffmpeg on the system. Set dry_run=true to preview the plan without running anything.

Retrieve a long-running generation that was submitted earlier but hasn't finished — any result from a generation tool that came back as {status:"pending", ...} (a job handle, not media). Pass the exact pending handle object(s) in jobs; NEVER re-submit a pending job with the tool that created it — that starts (and bills) a new one. Each job comes back one of three ways: finished (a hosted URL plus a local file path); still pending ({status:"pending", ...}), in which case call job_status again with the same handle after a short wait; or failed, carrying ok: false and an error. A failed job is terminal — it will never finish, so report the error and never poll or re-submit that handle. A batch can mix all three, so read every entry in results rather than the top-level counters alone. This works for any kind of pending generation and only rejoins an existing job — it neither starts nor bills a new one.