Skip to content

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 default profile ships five ready-made prompts (campaign_brief, analytics_deep_dive, surface_network_planner, content_optimizer, platform_onboarding; mosaic://capabilities lists the ones your connection has). Each returns a structured multi-step recipe naming exact tool calls — check whether one covers your task before hand-rolling a pipeline below.

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.

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, Meta Ads included when summary.meta.included is true) vs Reach (distinct sessions) called out separately, with Meta reach (summary.meta.reach) as its own figure, one insight per campaign maximum. For which creative did the work, request the creatives section: report each creative’s figures per channel with their source (“Reported by Meta” or “Measured by SparkleTree”), compare click-through per channel rather than one blended rate, and report the “not linked to a creative” rows as they are, never shared out across creatives.
  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.

  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 render 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 description and poll; there is no frame-level editing to orchestrate.

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.

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.