Skip to main content
Murph is the assistant built into the Scope3 platform for storefront operators. It works alongside you in chat to set up your storefront, connect inventory sources, compose products, and surface the analytics you need to negotiate and sell. Murph is available to every storefront account — open the Ask Murph panel from your storefront workspace to start a conversation.
This page is written for storefront operators. Buyers have Murph too — with buyer-side powers, a buyer Dashboard, and the same Your requests list — and can also work directly through the Buyer API and the Merchandising Agent.

​
What Murph helps with

​
Connecting your ad server

Murph guides you through connecting an upstream inventory source rather than asking you to hand over secrets in chat. For password- or token-based ad servers, Murph links you straight to the secure credential form, waits for you to submit, then runs a connection test to confirm the source can authenticate. For Google Ad Manager, no password is needed at all: Scope3 creates a service account dedicated to your account, and you grant that service-account email access inside your GAM network. Before walking you through the grant, Murph explains what access Scope3 needs, what it will not do, and what the granted role allows — and asks for your explicit consent first.
Scope3 stores only non-secret display fields for a connection. The upstream ad server holds the encrypted secret and mints short-lived tokens as needed. See Storefront onboarding for the full connection flow.

​
Uploading setup documents

You can upload PDFs, decks, spreadsheets, images, and text documents during a conversation. Murph summarizes them into structured facts instead of copying the raw contents back, so it can reference your brand book, rate card, or do-not-air list in later turns without re-reading the whole file. For brand books, Murph can identify brand-manifest candidates — name, website, colors, fonts, tone, tagline, and disclaimers — and help you draft or compare the fields that map into a brand.json. When you upload or link to canonical brand artifacts, Murph compares what it learns against the current AAO brand.json state and calls out new information, changed values, conflicts, and assets that still need public URLs. For logo images, Murph can upload the asset to AAO for review; pending uploads are tracked but are not used in brand.json until AAO approves and lists the public /assets/brands/... URL. Murph can preview the exact brand.json update and, after you confirm it, publish it to AAO for your verified storefront operator domain. For media kits, advertiser policies, and insertion orders, the offline scan also produces separate setup candidates when the document supports them: a business profile patch, complete acceptance-policy markdown (including every category the document says needs review), and URL-free AdCP 3.1 creative-format declarations. Murph presents each candidate for confirmation. Nothing is silently applied, and confirming one candidate does not approve the others. If a policy is incomplete or too long for complete inline review, Murph marks it as not writable and sends you to the Acceptance Policy page and original document instead of applying partial text.

​
File attachments

Murph accepts file attachments on a per-turn basis, with these limits:
  • Creative media files (MP4, QuickTime, MP3, WAV, and M4A) and ZIP creative bundles are accepted up to 50 MB decoded size. Every other attachment type is capped at 5 MB decoded size.
  • The total decoded payload across all files on a single turn is capped at 50 MB, even when you attach more than one file.
Media uploads are treated as transient creative assets for the current turn. Murph hands them to creative tools through murph-attachment:// placeholders. For MP3, WAV, and M4A audio up to 7 MB, Murph also transcribes the upload so you can talk through a request or ask about spoken content; the transcript is treated as untrusted user content. Transcription uses Gemini 3.5 Flash through Scope3’s governed Vertex AI connection; it does not use an uploader-supplied API key. Larger audio files remain available as creative assets but are not transcribed inline. The raw media bytes are never decoded as text. Attachments are not persisted to conversation history, so if a follow-up turn needs the same file, attach it again or first write it into durable Interchange state through a creative tool.

​
Stopping a response

While Murph is working on a turn, a Stop control appears in the composer. Pressing it ends the turn right away instead of making you wait for it to finish — useful when a request is taking longer than you want, or when you’d rather rephrase and ask again. Stopping halts Murph at the next step in its work. A step already underway — a model response or a tool call that is mid-flight — runs to completion; Murph stops before starting the next one.
Stopping does not undo work Murph already completed on that turn. If Murph had already made a change before you pressed Stop — for example, applying a setting or saving a value — that change stands. Stopping only prevents the remaining steps. The reply on a stopped turn says so. To control a durable write before it happens, use Murph confirmations, where protected writes wait for your explicit approval.
A chat response for a halted turn includes stopped: true. It is omitted on turns that run to completion.

​
Seller analytics and merchandising

Ask Murph for seller analytics and it can show your recent performance — win rate, buyer asks, top surfaced products, and the commercial outcomes attributed to your discovery runs. Murph turns that history into directional negotiation guidance and a recommended posture, and the same recent outcomes can tune the Merchandising Agent’s negotiation defaults when composing products. Your human operating instructions always remain authoritative over these historical defaults — Murph’s analytics inform the suggestion, they don’t override your rules.

​
Your requests and support

An ask is anything you are waiting on Scope3 for. Ask Murph to show your current requests to see them in one view, grouped by kind:
  • Support — problems, confusion, and blockers. Active support asks can show when the next update is due and whether you have confirmed that you are still blocked.
  • Product — ideas and feature asks tracked for product review. Tracking an ask is not a commitment to build it. When you state a clear product idea, Murph adds it to this list automatically; you do not need to file a separate support ask or repeat the request. If the same ask is already open, Murph keeps the existing item instead of creating a duplicate. If product tracking is not available for your account or Murph cannot verify the write, it says that the ask was not confirmed instead of claiming it was recorded.
  • Supply (buyer accounts only) — seller, property, and channel inventory a buyer wants Scope3 to carry.
  • Integration — a counterparty we do not connect to yet, named by vendor.
  • Commercial — pricing, terms, billing, and rate-card exceptions. Kept apart from support so a commercial question is not queued as an outage.

​
What each status means

Every ask uses the same short status list. Open statuses describe Scope3’s progress. Done and Closed describe Scope3’s outcome only; your confirmation remains separate. Each ask also includes a customer-facing label and explanation. Internal workflow states, ticket names, and engineering identifiers are not shown. For support, product, and commercial asks linked to delivery work, closing an issue or merging a pull request is not enough. The ask reaches Done or Closed only after the explicitly linked work appears in a verified production release. It then remains in your recent history for 90 days with the release version and date, what changed or why no change was made, what you should do next, and delivery status. Supply and integration asks can also finish from their own customer-visible live-state evidence.

​
Reading your asks from the API

Your own agent or integration can read the same list directly:
The response is read-only and scoped to your account from the API key you call with — there is no customer parameter, and you can only ever read your own asks. Each item carries statusKey (the values above) plus statusLabel and statusDescription for display, and a call returns at most 25 asks alongside hasMore. When hasMore is true, pass nextCursor back as cursor to read the next page. See the buyer and storefront API references for the full shape. On /mcp/v3, use search with kind: "ask", then pass the returned opaque id to get with the same kind. Record your own answer with save_ask, the opaque id, and requesterState; ask content and Scope3’s status remain read-only. When you explicitly ask for a person, Murph prepares the support ask first — it does not make you repeat the request or wait through diagnostics. For a blocker without a direct human request, Murph uses available diagnostics or safe recovery steps before preparing the ask. Either way, customer-authored filings wait for your approval before they create team-visible work. The ask content and Scope3 status are read-only and scoped to your account. Tell Murph whether the requested outcome happened, you acknowledge a no-change answer, you are still blocked, or you want to withdraw the ask. Internal routing identifiers are not shown. If one source cannot be read, Murph labels the view as partial — the API reports that source in unavailableKinds — instead of saying that you have no requests. A bounded result may also say that it is showing the first set of requests rather than implying the list is complete. Every kind shows open asks plus explicitly fulfilled asks from the 90-day recent history described above. During the transition from the older support ledger, some existing support asks may not yet include the next-update or still-blocked details, but every returned ask has an opaque id.

​
Compatibility payload for older clients

Older chat clients receive support-ask filing results in fields named escalated and escalation. These are deprecated wire-format keys, not a second customer object or lifecycle. Render the object as an ask, and check linearVisibility before rendering any legacy Linear reference.
linearVisibility can be: After Murph files it, ask Murph to show your current requests. In Interchange, the same tracker is available from the ? menu. In Slack, ask Murph for the status in the thread where you filed the request.

​
Working in the Dashboard

Ask Murph includes dashboard surfaces so you can review your state without leaving Murph. Sellers can open Dashboard from the storefront rail, or ask Murph for seller analytics. It opens the current seller analytics widget in chat, showing recent performance, buyer brief outcomes, delivery, and merchandising guidance from the same storefront analytics surface. Buyers see a separate Dashboard view with Overview, Reporting, Activity, and Creatives, plus an advertiser selector to scope each tab to a single advertiser. Buyers also get a Browse storefronts item in the sidebar that opens the full marketplace browse page inside the Murph shell.

​
Working in Diagnostics

Ask Murph also includes a Diagnostics view under the Help menu. Use it for the storefront-wide change history and protocol-call evidence behind a product or setup question. The Debug calls tab shows recent ADCP protocol activity for connected sales agents. You can open it directly with:
For an actionable health verdict and a no-spend get_products test against a third-party sales agent, open the Sales Agent Diagnostics app instead:
When you ask about a sales-agent source in Slack, Murph provides the same link as an Open sales-agent diagnostics button because Slack cannot render the MCP app inline. For the full workflow, see Diagnose third-party sales agents.

​
Murph in Slack

Scope3 can invite Murph into a shared Slack channel with your team. A channel is connected to exactly one account; once connected, Murph answers account questions there with that account’s data. Tag @Murph, use /murph, or send Murph a direct message when you want a response. In a channel message, the leading mention is the addressee: a message that starts by tagging another person stays ambient even if it mentions Murph later. You can include a supported file with an @Murph request or in a DM for Murph to review. A top-level file uploaded to the shared channel without a caption is treated as ambient channel content, so Murph stays silent. Ordinary replies between people stay ambient too, even when they include account-specific troubleshooting details. Murph uses the Slack thread as the durable conversation. When a follow-up is posted as a new top-level message instead of inside the original thread, Murph also reads a small window of nearby channel messages so it can understand what the follow-up refers to. Those nearby messages are context only; they never change which account or tools the speaker is allowed to use. Murph also uses the channel name, topic, thread, and connected-account context to resolve informal company or product names before declaring them unknown. If one candidate is clear, Murph names that interpretation and answers from the available account or documentation evidence. If several candidates remain, it asks which one you meant. Context can help find the right record, but it never grants access or supplies identity for an account change. Not every participant in a shared channel has to be an Interchange user. If a participant’s Slack email is not linked to an Interchange account, Murph can still answer general product and documentation questions using the nearby channel context. That includes public storefront availability: a participant can ask for a public brand, storefront, or domain by name, and Murph can report the matching marketplace-listed storefront’s public status, channels, and regions. Murph does not need an account connection or an exact domain for that lookup. It cannot read account data, file reports, save preferences, or make changes for that participant. Account-specific work requires a linked Interchange user. Murph links unlinked participants to the Interchange signup and access-request flow. In a privately connected account channel, the participant receives a private Request access from admin button without re-entering their email; Murph uses the email supplied by Slack and asks that account’s admins to approve the request. Shared multi-company channels do not infer an account from the channel, so they continue to use the email-verified signup flow. Because a Slack channel can include people from outside your organization, Murph regularly checks who can read each connected channel. If the members of a channel span more than one account — for example, a channel shared between a buyer and a publisher they work with — Murph pauses account-specific answers in that channel and says so, rather than showing one account’s data to another company. General product questions and DMs are unaffected. A Scope3 admin then reviews the channel: they can re-confirm it for account use or leave it as a general-questions channel. If your channel was paused and you believe the audience is expected, ask your Scope3 contact to review it.

​
Deliberately shared channels

Some channels are shared with another company on purpose — for example, a channel between a buyer and a publisher they work with. A Scope3 admin can tell Murph in that channel to mark it as shared and name each participating company. Murph resolves the companies, shows their buyer or seller roles, and records one acting account plus the expected counterparties. For a buyer–seller channel, the buyer is the acting account and the seller is the counterparty. If the roles are ambiguous, Murph asks the admin to choose instead of guessing. Declaring a buyer–seller channel is also demand evidence: the buyer has a working relationship in which it wants that seller’s supply. Interchange automatically tracks the seller’s marketplace-visible storefront relationship in the buyer’s Supply I would buy view. Those relationship-tracked rows stay attached to the shared-channel declaration and cannot be removed as if they were a manual request. In a shared channel, Murph:
  • Discusses the relationship freely — supply you’ve asked to track for that counterparty, whether it’s ready, and general product questions.
  • Keeps everything else out of the channel. Your other sellers, campaigns, advertisers, spend, and account settings are never discussed there — Murph redirects those questions to a DM or your private channel. Supply tracking in the channel works only for the counterparty’s own domains.
  • Lets you approve specific exceptions. If a campaign of yours is relevant to the shared work, you can tell Murph to share it in the channel. Murph asks you to confirm explicitly — “Is it okay to share this campaign’s details here?” — and only someone from the owning company can approve. Once approved, its settings-level details (name, status, flight dates, budget) stay discussable in that channel until you say “stop sharing it here.” Every approval and revocation is recorded.
  • Keeps watching the room. If someone from a third company appears in the channel, Murph pauses account answers again until an admin reviews.

Storefront onboarding

The end-to-end flow for standing up a storefront and connecting inventory.

Storefront object guide

The storefront resource, business profile, and seller analytics fields.

Sandbox

Test plans and diagnostics for validating your storefront before launch.

Shared Murph rooms

Bring teammates into a Murph conversation with a shareable room link.

Third-party agent diagnostics

Find source health, recent ADCP debug calls, and missing diagnostic gaps.

Murph user preferences

Set Murph’s default language and read display preferences for the current user.

Conversation scope

Bind a Murph conversation to your account or a single advertiser.

Management UI

Navigate the platform dashboard for members, keys, and accounts.