Advanced workflows

Recipes that chain tools into complete jobs. Written for a capable agent orchestrating on a user’s behalf — in a chat client, Claude Code, the codex CLI, or similar. Ground rules from tips-and-tricks.md apply throughout: query before manage, confirm mutations and credit spend, poll async jobs.

Tip: The server ships six ready-made prompts (campaign_brief, analytics_deep_dive, surface_network_planner, content_optimizer, ai_studio_image_workflow, platform_onboarding). Each returns a structured multi-step recipe naming exact tool calls — check whether one covers your task before hand-rolling a pipeline below.

A. Product URL → live campaign

Turn a product page into a deployed campaign.

1. manage_products action: import_from_url with the product URL. Import reaches the open web and pulls the product into the catalog.
2. Confirm with the user (credits), then generate_campaign mode: start with an intent describing the goal and the imported product.
3. Poll query_campaigns action: generation_status until complete. Don’t spin; don’t restart.
4. query_campaigns action: variants on the new campaign. Present the variants to the user; apply requested edits with manage_campaigns action: update_variant. If a variant misses, generate_campaign mode: regenerate (confirm credits again) rather than hand-patching everything.
5. On approval: manage_campaigns action: publish, then action: deploy to the chosen surface (query_surfaces operation: list_surfaces to find it). Publish/deploy trigger republish automatically.
6. Verify: fetch the brand page’s public markdown twin (Accept: text/markdown on the brand host) and confirm the campaign is live.

B. Weekly analytics digest

A recurring report with proposed actions, human in the loop.

1. query_analytics action: snapshot with default sections: ["summary"] for the top line; widen sections only where the story needs detail.
2. query_analytics action: cvg_dashboard for per-variant performance and winner detection.
3. Summarize: winners and stalls per campaign, Impressions (raw delivery) vs Reach (distinct sessions) called out separately, one insight per campaign maximum.
4. Propose concrete variant edits — copy tightening on the laggard, retiring a clear loser — as a diff-style list. Do not apply anything yet.
5. On explicit approval, apply each with manage_campaigns action: update_variant (or delete_variant). Saves republish automatically.

The analytics_deep_dive server prompt is the ready-made version of steps 1–3.

C. Video from a winning campaign

1. query_analytics action: cvg_dashboard to identify the top campaign/variant over the window the user cares about.
2. query_video action: templates to list available templates — a free read.
3. Confirm the credit spend and the chosen campaign with the user, then render_video mode: campaign (or mode: video / mode: still per the ask).
4. Poll query_video action: progress at a reasonable interval until the render completes; report the result.

Rendering is automated and quality-gated server-side — you submit the brief and poll; there is no frame-level editing to orchestrate.

D. Brand-site Q&A bot — no MCP, no auth

Answer visitor questions about a brand using only its public surfaces. No account, no OAuth, no MCP session.

1. GET https://<brand-host>/llms.txt — the entry map to the brand’s content.
2. Optionally fetch /.well-known/agent-card.json and the agent skills index (/.well-known/agent-skills/index.json; the ask-venue SKILL.md documents the concierge contract — verify its sha256 digest).
3. Fetch relevant pages as markdown twins via Accept: text/markdown for grounding.
4. POST /ask with the visitor’s question — the brand’s own concierge answers from its published content.

This is the right architecture whenever the task is consuming a brand rather than operating a workspace: cheaper, faster, and zero credentials to manage.

E. Multi-workspace agency ops

Each MCP connection is bound to one workspace; cross-workspace access is refused. For an agency operating several client workspaces:

1. Maintain one connection (or API key) per workspace — separate connector entries, or separate x-api-key values from each workspace’s Settings → API keys.
2. Before every batch of actions, get_platform_info topic: organization on the active connection and echo the workspace name back to the user. Never infer scope from memory — a wrong-workspace publish is the expensive failure mode here.
3. Run the same recipe (A–C above) per workspace, re-confirming scope at each switch.
4. For cross-client reporting, run recipe B per connection and merge the digests client-side; there is no cross-workspace query.