> ## Documentation Index > Fetch the complete documentation index at: https://docs.interchange.io/llms.txt > Use this file to discover all available pages before exploring further. # Ask Murph > Murph is the in-product assistant that helps storefront operators set up, merchandise, and run their storefront 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. Murph is the operator-facing assistant. Buyers interact with your storefront through the [Buyer API](/v2/buyer-introduction) and the Merchandising Agent, not with Murph directly. ## What Murph helps with | Area | What Murph does | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | **Storefront setup** | Walks you through onboarding, captures your [business profile](/v2/object-guides/storefront), and gets your storefront ready to sell. | | **Connecting inventory** | Sends you to the secure forms for ad servers like Google Ad Manager, FreeWheel, and SpringServe, then verifies the connection. | | **Setup documents** | Reads uploaded brand books, media kits, rate cards, and operating instructions so you don't have to paste them into chat. | | **Merchandising** | Helps compose products and tune negotiation defaults using your recent storefront outcomes. | | **Seller analytics** | Surfaces win rate, buyer asks, top products, and recommended negotiation posture so you can see what's working. | | **Sandbox testing** | Runs and reports on [sandbox test plans](/v2/features/sandbox) so you can validate behavior before going live. | | **Shared rooms** | Turns a conversation into a [shared room](/v2/features/murph-shared-rooms) teammates in your organization can join. | | **Diagnostics** | Opens source health, ADCP debug calls, test runs, and change history so product questions can be answered from live evidence. | ## 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](/v2/setup/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](/v2/setup/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 Ask Murph to show your current requests to see one view grouped into three kinds: * **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 escalation 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** — seller, property, and channel requests being watched through the supply workflow. When you describe a blocker or ask for help, Murph first interprets the request and uses available diagnostics or safe recovery steps before preparing a support escalation. A generic escalation is not prepared until that triage is complete, and it still waits for your explicit approval before it is filed. The view is read-only and scoped to your account. Internal ticket and channel identifiers are not shown. If one source cannot be read, Murph labels the view as partial 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. Support includes active cases and a short window of recently resolved cases. Product and supply show their current open views. During the transition from the older escalation list, some existing support requests may not yet include the next-update or still-blocked details. ### When Murph files a support escalation When Murph files an escalation, chat responses include an `escalation` artifact with the filed status and, when available, the linked Linear issue. Clients should check `linearVisibility` before rendering Linear references. ```json theme={null} { "escalated": true, "escalation": { "linearIdentifier": "MURPH-123", "linearUrl": "https://linear.app/scope3/issue/MURPH-123/example", "linearVisibility": "visible", "slackPosted": true, "severity": "medium" } } ``` `linearVisibility` can be: | Value | Meaning | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | `visible` | `linearIdentifier` and `linearUrl` may be shown to the caller. | | `hidden_for_role` | Linear exists, but the current caller is not allowed to see the Linear reference. Treat `linearIdentifier` and `linearUrl` as hidden, not missing. | | `unavailable` | Linear was not configured, failed, or did not return a reference. | 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: ```text theme={null} https://interchange.io//murph?view=diagnostics&diagnosticsTab=debug-calls ``` 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: ```text theme={null} https://interchange.io//murph?view=chat&askMurph=open_feature&feature=source-health ``` 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](/v2/storefront/inventory-sources/diagnostics). ## 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. The end-to-end flow for standing up a storefront and connecting inventory. The storefront resource, business profile, and seller analytics fields. Test plans and diagnostics for validating your storefront before launch. Bring teammates into a Murph conversation with a shareable room link. Find source health, recent ADCP debug calls, and missing diagnostic gaps. Set Murph's default language and read display preferences for the current user. Bind a Murph conversation to your account or a single advertiser. Navigate the platform dashboard for members, keys, and accounts.