The signed-in account, its plan, and everything it has left: AI Studio credits, reels today and this month, automated posts, workspace slots and storage. Call this before any generation — the limits here are enforced server-side, so a job that exceeds them fails rather than queues. Also names the workspace the other tools will act on by default.

Every workspace on the account, with the active one marked and the plan's workspace allowance. A workspace is a separate brand: its own content, its own connected social accounts, its own analytics. Check this before acting when the account might have more than one.

Set the workspace every later tool call acts on, for the rest of this session. Takes a workspace id from list_workspaces. This only changes where THIS MCP connection points — it does not move the workspace switcher in the user's browser.

Add a workspace — a separate brand with its own content and connected accounts. Fails with a plan-limit message when the account is at its allowance. Does not switch to it; call use_workspace afterwards.

Rename a workspace. Renaming also marks the name as human-chosen, which stops a later brand scrape from overwriting it.

PERMANENTLY delete a workspace and everything in it — generated reels, library uploads, scheduled posts, analytics history and connected social accounts. There is no undo and no export. Refuses to delete the account's last workspace. Always confirm the exact workspace name with the user before calling this.

The workspace's brand: website, description, and the voice settings (brand name, @handle, niche, default platform, whether posts mention the brand). This is what the caption writer and the UGC prompt builder draw on, so read it before writing copy so the result sounds like the brand rather than like a generic ad.

Change how captions sound. Only the fields you send are changed; the rest are left alone. The @handle is globally unique — if it is taken the call fails with a suggestion you can offer the user.

Fetch and summarise a website so the brand can be described from it. Use this when the user gives a URL and you need to know what the business actually is before writing copy or setting the brand. Returns the extracted content; it does not save anything.

The TikTok, Instagram and YouTube accounts connected to this workspace, with the ids that scheduling tools need. Connections are per workspace. New accounts can only be connected in the browser — this cannot start an OAuth flow.

Disconnect a social account from this workspace and revoke the app's access with the platform. Already-published posts stay; anything still scheduled to it will fail. Reconnecting requires the user to go through OAuth in the browser again.

The workspace at a glance: lifetime views and likes, published count, the last five reels with their status, and what is scheduled next. The best first call for 'how am I doing'. Sections degrade independently — a section marked 'unavailable' failed on its own and the rest of the payload is still good.

Deeper performance for the workspace: totals, daily series, per-platform breakdown, top posts and posting-hour patterns. Use this over get_dashboard when the question is about trends, what performed best, or when to post.

Every post in the workspace — published, scheduled, publishing and failed — with captions, platforms, times, per-post metrics and the account each went to. Capped at the 500 most recent. A post fanned out to several accounts appears as one row per account sharing a reel id and publish time; the scheduling tools treat that group as one unit.

Metrics for specific posts by id, including how they moved over time where snapshots exist. Use after list_posts when the question is about particular posts rather than the workspace as a whole.

Recent notifications for the account — finished renders, failed publishes, allowance warnings. Useful for answering 'did anything break' without reading every post.

Mark notifications as read — either specific ids, or all of them at once with all=true.

Media in the workspace library — uploaded clips and images, with ids, titles, folders and storage keys. The ids here are what reference-taking generation tools expect.

Folders the workspace's library media is organised into.

Create a library folder to organise media into.

Move library media into a folder, or out of every folder by passing folderId as null. Moves are metadata only — nothing is re-uploaded and no file changes.

Permanently delete one piece of library media and free its storage. Posts already published with it are unaffected, but anything still referencing it will lose the file. No undo.

The image and video models available, with their tiers, aspect ratios, durations and per-image or per-second credit cost. CALL THIS BEFORE generate_image or generate_video — model and tier ids are not guessable, an unknown one is rejected, and the price difference between tiers is large enough to be worth choosing deliberately.

Generate images from a prompt. COSTS CREDITS — between roughly 1 and 24 credits per image depending on model and tier, charged whether or not the result is used. Get valid model, tier and aspect values from list_studio_models first, and check the balance with whoami. Returns straight away with the generated images; there is no separate job to poll.

Recent image generation runs in this workspace, with their prompts, images and the credit balance. Use to find an earlier result rather than paying to regenerate it.

Start a text-to-video generation. COSTS CREDITS — priced per second, from about 5 to 53 credits a second depending on model and tier, so a 5-second clip ranges from ~25 to ~265 credits. Charged when the job is accepted, not when it succeeds. Get valid model, quality, duration and aspect values from list_studio_models, and check the balance with whoami first. Returns a job that renders in the background; poll it with get_video_job.

The current state of one video generation — queued, running, done or failed — and the clip when it has finished. Video takes tens of seconds to minutes; poll every 10-15 seconds rather than in a tight loop.

Recent video generations in this workspace with their status and clips, plus the credit balance. Set completedOnly to skip anything still rendering.

Delete a generated video and its clip. Credits already spent are NOT refunded — deleting removes the result, not the charge. No undo.

Slideshow drafts and finished sets in this workspace.

One slideshow in full — its slides, their copy and their images.

Build a slideshow from one of the built-in template sets. COSTS CREDITS — the copy is written by an LLM and each slide is a generated image, so cost scales with the slide count. Get image model and tier ids from list_studio_models. Use list_slideshow_templates for valid set ids.

The template sets create_slideshow can build from, with their ids and what each one is for.

Write a caption and hashtags in the workspace's brand voice for a piece of content. Costs a small amount of the account's text allowance. Requires a brand on the workspace — without one it fails with a 409 telling you to set a website first. Prefer this over writing captions yourself: it reads the brand voice, which you cannot see in full.

Schedule an already-generated video or image to publish to connected social accounts. THIS PUBLISHES PUBLICLY at the time given — confirm with the user before calling. The generation must have finished. publishAt must be at least ~2 minutes in the future. Selecting several accounts fans out to all of them as one group.

Change when a scheduled post publishes. Pass EVERY id in the group — a post sent to three accounts is three rows sharing one time, and they must move together; a partial list is refused rather than splitting them. Only works while the posts are still 'scheduled', and the new time must be a few minutes out.

Cancel posts that have not published yet. Anything already published or mid-publish is silently skipped — this cannot unpublish. Pass every id in a fanned-out group to cancel it whole.

Automations in this workspace. An automation is a planned run of posts across a date range — it generates a lineup of content, which a human approves, and then publishes on a schedule.

One automation in full, including its planned items and their individual states.

Plan a run of posts across a date range. This creates the plan and reserves allowance; it does not publish anything until publish_automation is called on it. The daily slot ceiling comes from the plan — read automationSlotsPerDay from whoami before choosing postTimes.

Change an automation's name, schedule or target accounts. Items already published are not affected.

Approve an automation's lineup and commit it to the publishing schedule. THIS IS THE POINT OF NO RETURN — from here the posts go out to real accounts on their planned times without further confirmation. Always show the user the lineup from get_automation and get explicit approval before calling this.

Delete an automation and cancel everything it still has scheduled. Posts it already published stay up. No undo.

What the Rush deck is currently tuned to — the content mix and the categories it draws from.

Deal the next cards from the Rush deck. NOT a plain read: cards dealt here are counted against the account's daily reel allowance as soon as they are in hand, and stay counted until each one is kept or skipped with resolve_rush_item. Ask the user before dealing a large batch, and resolve what you deal.

Decide a card that has been dealt — keep it, which turns it into a reel, or skip it, which returns its hold on the daily allowance. Every card from get_rush_feed should end up here.

Turn Rush cards you have already dealt into a dated plan. This is the only way to get a Rush pick onto a calendar — resolve_rush_item records a verdict but builds nothing, and create_automation invents its own content instead of taking yours.

PUBLISHES NOTHING. It returns a draft automation: no video is rendered and no post exists until publish_automation is called on the id it hands back. That makes this safe to call before showing the user anything.

The whole flow, in order:

1. get_rush_feed — deal cards.

2. schedule_rush_lineup — send the ones you want (this tool). Do this BEFORE step 3: if the plan is refused, the deck is left exactly as it was, whereas resolving first would close cards for a run that never existed.

3. resolve_rush_item with 'keep' for each card you sent, and 'skip' for the rest, to clear the hand.

4. get_automation — read the lineup back and show the user the dates and copy.

5. publish_automation — only after the user has explicitly approved. This is irreversible.

Dates are worked out for you: it spreads the items from startDate over postTimes and returns the exact instant each one landed on, so you never compute a timestamp yourself.

ALWAYS PASS timezone. It is the one default that will embarrass you. Omitted, the zone saved on the account is used, and accounts often have none saved — which falls back to UTC, so an evening slot for a user in Asia/Kolkata is planned at half past one in the morning. Pass the user's IANA zone every time unless they actually want UTC.

startDate defaults to tomorrow, which is usually right. postTimes defaults to a spread that fits the items into the days available; it is a reasonable shape but it knows nothing about when this audience is awake, so prefer the times the workspace already posts at — list_posts shows the existing cadence. Note the plan-window check is on startDate only, so a long run can still spread past the date the plan is paid through.

Refusals worth knowing before you call: a lineup may hold at most 200 items; postTimes cannot be longer than the plan's reels-per-day (read reelsPerDay from whoami); and a run cannot start after the date the plan is paid through, so check periodEnd in whoami if the user wants something far out.