SuperCMO

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 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 — not the page's full text — plus page metadata. Omit both prompt and schema to get the page's own text (markdown) instead, which costs less, together with the colours, fonts and logo the page renders (branding) and a screenshot URL of the page as a visitor first sees it. A page that answers HTTP 400 or above comes back as a failed read. Use when you need specific data, image URLs or the text of a page. Set dry_run=true to preview the exact request without spending.

Look at one or more images (local file paths or image URLs) and answer a question about each — returns text, not new images. 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. Pass `requests` to read several images in ONE call — they are analyzed in parallel, so a batch costs about the same wall time as its slowest image. 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 one or more videos (local file paths or video URLs) and answer a question about each — returns text, not new video. Use to read a clip before generating or matching it, to describe what happens in it, or to transcribe what is said. Pass `requests` to watch several videos in ONE call — they are analyzed in parallel, so a batch costs about the same wall time as its slowest clip. 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.

Pull read-only structured public data from social platforms and ad libraries — competitor ads (Meta/Facebook + Instagram, LinkedIn), profiles, posts, comments, transcripts, hashtag/keyword search, and subreddit / trend discovery. Two steps: call list_research_sources FIRST to see the platforms, their endpoints, and each endpoint's params; then call this with `platform`, `endpoint`, and a `params` object built from that endpoint's required/optional params. Returns the source's structured JSON in `data`, or a structured error naming the missing or unknown params. Known endpoints are projected to their readable fields and one media URL per item, with page-level facts carried once in `advertisers` rather than repeated on every row, and `shaping` says what was dropped; `fields` widens or narrows that. Every response is also written to a file: `saved` carries its `path`, the run's `output_dir` for anything built from it, the count and the cursor, so a response can be handed straight to a script without being copied out of the conversation. Where the response is too large to read, `saved.inline` is false and `data` is omitted — use the file. Use for competitor and market research, audience listening, and trend discovery — this is read-only public data, not posting and not private data. Set dry_run=true to preview the exact request without spending.

List the available research sources for social_research — every platform, its endpoints, and each endpoint's required and optional params plus per-call cost. Call this FIRST whenever you need competitor ads, profiles, posts, comments, transcripts, or platform search and don't already know the exact platform + endpoint + params. Pass an optional 'query' to filter by platform, endpoint, or keyword (e.g. 'ads', 'reddit', 'comments').

Transcribe speech from an audio or video file into text with word-level timestamps. Use it to caption a video (chain transcribe -> caption_video), to read a voiceover back, or to analyse a competitor ad's spoken script. `audio` is a local file path or an http(s) URL (audio or video). Returns {ok, text, words:[{word, start, end}], duration, language}, or a structured error. 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. Three optional layers, each its own parameter: lay a voiceover over the picture (pass `narration` — ONE take per clip, in clip order, NOT one joined track; each take is aligned to its own clip so nothing drifts), 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.

Burn styled, social-style captions into a video from a word-timed transcript — local ffmpeg, no credits. The usual chain is transcribe -> caption_video: run transcribe on the video (or its voiceover) to get word timestamps, then pass those here. Captions are styled and positioned with a font bundled in the package (no system-font dependency); optional karaoke highlights each word as it is spoken. Timestamps are relative to the video's own audio (t=0). Returns the output file `path` with its duration, resolution, and size, or a structured error with a hint. Requires ffmpeg. Set dry_run=true to preview without rendering.

Stamp a logo, timed text, and a branded end card onto a video — local ffmpeg, no credits. Overlay a logo watermark at a chosen corner, drop in timed text (CTAs, offers, captions you place yourself), and/or append an end-card image as a short closing still. Pass at least one of logo / texts / end_card. Text is rendered with a bundled font (no system-font dependency). Returns the output file `path` with its duration and resolution, or a structured error. Requires ffmpeg. Set dry_run=true to preview.

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.

List the caller's calendar events — tasks and posts — ordered by when they next fire. Each event includes a computed `next_occurrence`: the ISO-8601 timestamp of its next fire time, derived from the event's `at` or `rrule` so the caller never has to compute recurrence itself. Defaults to upcoming, still-scheduled events; pass `status` to also see cancelled or historical (done/failed/missed) events. Narrow further with `window_start`/`window_end` (a time range), `kind` (task vs post), or `channel` (exact match on the free-text channel), and cap how many come back with `limit`. Use this before calendar_add to check for a clash, or before calendar_update/calendar_remove to find the event's `id`.

Schedule a new calendar event that fires once or on a recurrence. Two kinds: 'task' re-invokes the agent with `prompt` when it fires — write the prompt as a complete, self-contained instruction, since the agent has no memory of this call when it runs. 'post' publishes prepared `content` through a named tool with no model call in the loop — requires `content`, `channel`, and `publish_tool`. Exactly ONE of `at` (a one-shot ISO-8601 timestamp, which must be in the future) or `rrule` (an RFC 5545 recurrence rule) is required — never both, never neither. `channel` is free text, not a router: it is a hint the tool named in `publish_tool` reads to decide where to post, so word it the way that tool expects, never a fixed enum. `publish_tool` must name a tool the caller can actually call right now — a currently-connected tool, never invented or assumed; the event hard-fails at fire time if the named tool is not connected. `media` is an optional list of local file paths and/or URLs to publish alongside `content`. `timezone` is an IANA name (e.g. 'America/New_York') the schedule is interpreted in.

Change fields on an existing calendar event, or re-arm/cancel it. Pass only the fields you want to change — anything omitted is left as it was. `kind` is fixed at creation and can't be changed here. The same rules as calendar_add apply to whatever you set: exactly one of `at`/`rrule` if you're changing the schedule, and `content`+`channel`+`publish_tool` together if the event is a 'post'. `channel` stays free text read by `publish_tool`, never a routing enum, and `publish_tool` must still name a currently-connected tool. Pass `status: "cancelled"` to cancel the event without deleting it, or `status: "scheduled"` to re-arm a cancelled one.

Cancel a calendar event by `id` — it stops firing but is not deleted, the same effect as calendar_update with status='cancelled'. Use calendar_list first if you don't already have the event's `id`.