Browse docs
Sprid docs

Use Sprid in chat

Connect Sprid via MCP, use your chat images and review delivery in your browser.

What this guide does: Prepare a campaign from its business goal, tracking and creative, or take a post through review and confirmed delivery, using your chat app and a browser. No CLI or installed skills needed.

You tell the agent what you want; it handles the tool calls below. The tool names are here so the agent knows the order. Setup should only ask for the connection the current task needs.

For purchase or lead tracking, ask your agent to read the tracking setup guide, available through get_documentation {topic: "tracking"}. It explains the checks and any handoff to a coding agent.

Connect Sprid

Open Get started, choose your chat app and follow its steps. Your chat may call this an app, connector or integration. The address is https://api.sprid.studio/api/mcp?surface=core&src=docs. Sign in to Sprid and authorize the right workspace.

Agent: once the app exists, start with get_marketing_plan and reuse its prepared work and next step rather than starting over. Discovery can start from a website or store URL, with no social account.

Pick the app and account

Agent: call get_capabilities, then list_apps and list_accounts, and reuse what exists. If the app is missing, get its description or website/store URL, confirm it and create it with upsert_app_profile. A content account owns voice and media; a channel is one exact social destination. Never pick a handle just because it is first in a list. If the app has no account, ask what to call it. Use create_content_account when your connector exposes it. If that tool is unavailable, open https://app.sprid.studio/settings/accounts/new?workspaceId=<workspace-id>&app=<app-id> with the selected app’s workspace and app IDs filled in. Ask the person to confirm that app and create the account, then read list_accounts again.

Then ask whether the app has users yet. If it does, offer the analytics and revenue connections next_actions lists first: each link opens Sprid’s secure form, and the first recommendation then reads real numbers. If it has none yet, continue the requested campaign, tracking setup or first post; connecting stays optional until that work needs it.

Prepare a campaign

For purchases, subscriptions, qualified leads or meaningful app use, start with the business goal and the place where the customer acts. A request to promote a successful post makes that post a creative candidate. Its organic response does not prove paid conversion performance. Boosting for reach or engagement is a separate, explicit goal.

Agent: check the paidCampaigns capability first. The following campaign tools are conditional on this connection exposing them. On a core connection, use find_tools and call_tool to discover and run tools outside the everyday list. If campaign tools are unavailable, read the campaign guide and tracking guide, preserve the goal and hand off to a connection with campaign tools or Sprid Ads. Do not try hidden tools on a directory connection.

  1. Read ad_campaign_context for the selected account and reuse the saved plan. Save the outcome, destination, funnel and bidding event with prepare_ad_campaign. This records a brief without creating platform objects.
  2. Read ad_measurement and follow the tracking guide. Inspect source receipts and destination diagnostics. Use record_ad_measurement_evidence to save dated, caller-attested checks for the exact network, channel, event target, build and environment. Keep delivery, duplicate handling, consent, matching and bidding eligibility separate. Configuration alone does not verify them; sandbox evidence does not verify production.
  3. Prepare compatible paused delivery objects only when requested. For Meta, use create_ad_campaign, create_ad_set, then create_ad_creative or create_carousel_ad_creative for suitable post assets and create_ads. For Google Search or App campaigns, use create_google_campaign with the chosen conversion actions and required assets; validation is the default. An Instagram post is not a Google campaign type.
  4. Review the destination, event, creative, budget and duration. For Meta, use preview_ads and ads_preflight. Spending requires a person in Sprid. A saved brief, tracking record or chat approval does not start delivery.
  5. Read ads_inventory and ad_council for Meta, or google_ad_research for Google. Compare results with the saved business goal. Keep actual purchases separate from platform-attributed purchases; never sum different networks’ claims as unique customers.

Tracking-only work stops at the evidence and unresolved checks. A no-campaign request stops before creating paused objects too.

Connect a destination or data source

  • Social channel: get_documentation with the platform name, then connect_channel. The person opens the returned link and approves in the browser; channel_status confirms the saved result.
  • Store or analytics: the person enters identifiers and the key in the secure form at https://app.sprid.studio/settings/app-profiles. Credentials never go in chat, tool arguments or reports. A saved-key indicator only proves configuration; get_marketing_review reports source status and freshness; inspect those before treating data as current.

Bring images or a finished video

Draft copy in the chat, in the account’s voice. No extra model key needed.

If the chat exposes the attached files, pass them to import_assets: each file has download_url and file_id, optionally mime_type and file_name. Public HTTPS URLs and existing {kind, id} library references also work. Limits: PNG, JPEG, WebP or finished MP4, up to 32 MiB each. Each position reports on its own; retry the missing ones before building the post. Files are copied to the account and deduplicated by bytes; temporary download URLs are not kept.

A sandbox: URL or local path can’t be fetched. For an image the chat generated, use the existing file if the host exposes it (not verified for every host); otherwise download it and use the browser upload. Never ask the agent to recreate an image or transcribe binary data.

Fallback: browser upload. Call create_upload_session with the account and a new UUID requestId. The person opens the link and picks the files. Then read get_studio_job with the returned ID; its result keys are zero-based positions. The same session and asset IDs work from any other chat. No image-generation charge.

Create and review the post

Call create_post with a new UUID requestId, the account, ordered {kind, id} assets, captions and aspect ratio. Reuse the same ID and inputs if a response is lost.

  • presentation: "finished" keeps artwork as-is: no text overlay, no added music. Images fit inside the canvas, which can add margins.
  • presentation: "editable" allows text and subtitle on image slides.
  • One finished video becomes one reel. Never mix a video with image slides.

Edit with update_post (captions) and update_slides (slides). Call preview_post and check every slide or the video: captions, order, crop, legibility. It returns a small image of each slide for the agent to look at and an embedded preview for the person; a chat without embedded apps still shows the images. A preview is not approval to publish.

Agent: show the person the preview, and link every post you mention with the links the tools return, as a Markdown link on its ref or title: links.review when the ask is to approve or schedule, links.editor when it is to change something. Never draw the slides in your own widget or artifact: those sandboxes block Sprid’s media host and the images show broken.

Make a reel from photos or text

Check get_capabilities for hosted creation first. create_reel takes ordered scenes (imageId, text, durationMs), up to 120 seconds, and makes a silent MP4. It uses the workspace’s render allowance: tell the person, and get their go-ahead before sending confirmed: true. Save the job ID and read get_studio_job. Retrying with the same ID never starts a second render; a stopped job reports needs_attention instead of running again.

To turn an existing post’s slides into a video instead, use its own video: get_video_capabilities, then get_post_video and the individually exposed video edit tools for transitions and motion. Use edit_post_video only when your connector exposes it; directory connections expose fixed edits such as video_set_transition with their full input schemas. Use update_post {outputs} for which destinations get it. Rendering it is metered the same way: quote_post_video_render, the person’s go-ahead, then render_post_video with confirmed: true. Schedule a video destination with the render’s videoRenderId.

App captures, simulator recordings and your own build scripts run outside remote MCP. Upload their finished files.

Approve and confirm delivery

Publishing and scheduling require the person’s approval of the preview and intended destinations. The browser review link remains available for picking channels, time and platform options.

TikTok requires an explicit postMode; nothing defaults to a direct post or a draft:

  • MEDIA_UPLOAD sends the media to the creator’s TikTok inbox. They finish the post in TikTok; report it as a draft.
  • DIRECT_POST requires privacyLevel, disableComment, disableDuet, disableStitch, yourBrandToggle, brandedContentToggle and confirmed: true in options.tiktok. Fetch fresh choices with list_connections {includeTikTokCreatorInfo: true} and show the creator identity, media and caption. The person chooses every setting for this post. Photo posts use disableDuet: true and disableStitch: true; comments respect the creator’s restriction. Branded content cannot use SELF_ONLY.

Before sending confirmed: true, get the person’s approval of this exact post and their agreement to TikTok’s Music Usage Confirmation, plus the Branded Content Policy for branded content. That flag is a caller’s attestation, not proof of a click in TikTok’s prescribed UI. Never invent choices or carry usual preferences into a new post. If choices are missing, open the returned approvalUrl for the person to answer in Sprid.

An approval covers the version the person saw. If you edit a scheduled direct post afterwards, the edit’s result carries tiktokApproval: the scheduled post will not publish as it is. Show the person the change and the settings in its rebook call, ask whether to post this version, and only after they agree call rebook with options.tiktok.confirmed: true added. post_queue returns the same call while the approval is outstanding.

Chat approval does not establish that TikTok’s required posting controls have been completed. Use the Sprid review link for those controls and consent before confirming delivery; do not describe chat-only approval as platform-verified.

After approval, read post_queue. Keep draft, scheduled, failed and delivered apart, and report delivery only with the platform receipt. Read a failure before retrying. Never repeat a publish call just because a response was lost.

For results, read get_documentation for marketing-review. Keep the same app, account and post IDs across clients. next_actions gives the next step; an empty verb means follow its browser link.

Limits and troubleshooting

  • Attachment can’t be read: use the browser upload, not the CLI.
  • Missing account or service: set it up in the dashboard. Never paste credentials into chat.
  • Hosted creation: check get_capabilities before promising it. Store screenshots and store releases are local unless it reports otherwise.
  • File transfer: whether a host exposes uploaded or generated files has to be checked per host. A supported schema doesn’t prove it.
Need a hand?
Colour theme
Back to Sprid ↗