> ## 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. # v3 storefront nouns: media kit, playbook, business rules (preview) > The three v3 /mcp/v3 nouns that replace the merchandising grab-bag — what each one owns, what get and search return for it, and the request/response shape of each save tool. **Preview.** `/mcp/v3` is behind a feature flag and no accounts are enrolled. `/mcp/v2/storefront` is unchanged and nothing here deprecates it — see [v3 Agent Surface](/v2/setup/v3-preview) for the shape of the surface as a whole. This page documents `save_media_kit`, `save_playbook`, and `save_business_rules`, plus what `get` and `search` return for them. There is no `merchandising` noun on `/mcp/v3`. **Merchandising is what your storefront *does*** — the [Merchandising Agent](/v2/concepts/merchandising-agent) selling on your behalf — not a thing you save. Three nouns steer it, split by what kind of fact each one holds: | Noun | Kind | Owns | | ---------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `media_kit` | material — what you show | Resolved identity (brand name, logo, membership badge), the authored story (summary, footprint, channels, regions, verticals, evidence links) | | `playbook` | judgment — how you sell | Value-anchor pricing facts (floor/target/ceiling per condition), posture, packaging and selection guidance | | `business_rules` | constraint — what you accept | The acceptance policy, and the two approval gates (`creativeApproval`, `mediaBuyApproval`) | This is a v3-only split. The four Pages you use today — **Selling Terms**, **Approval settings**, **Acceptance Policy**, and **Merchandising Rules** — are unchanged; see [Merchandising](/v2/concepts/merchandising) for how those map to the platform. This page describes only the agent tools on `/mcp/v3`. ## One fact, one owner Each fact has exactly one noun that owns it, and this is enforced, not advisory: a `playbook` version whose content restates a price, a discount, a market, or an acceptance rule is **rejected on save** — `save_playbook` returns an error rather than a warning. The reason is drift: `playbook` is prose your agent reads, `business_rules` and `media_kit` are the structured facts downstream logic enforces, and if a `$25` floor lived in both they would eventually disagree. Business rules is also where the platform's enforcement lives, which is why it is a separate noun rather than a section of `media_kit` or `playbook`: the approval gate reads `business_rules` before anything else runs, and its absence fails closed (see [Turning off human review](#turning-off-human-review) below). `media_kit` and `playbook` are inputs your Merchandising Agent composes with; nothing gates on them directly. ## Reading a noun: `get` takes no id `media_kit`, `playbook`, and `business_rules` are singletons — exactly one per storefront — so `get` identifies them by `kind` alone. Passing an `id` for any of these three is a validation error. ```json theme={null} { "kind": "business_rules" } ``` ```json theme={null} { "kind": "playbook", "include": ["versions"] } ``` `include: ["versions"]` adds the full version history for `playbook` and `business_rules` (an array of `{ version, isActive, notes, createdAt }`); omit it and `get` returns only what is currently active. There is no separate "list versions" tool — version history is an `include`, the same way source diagnostics are. ## `media_kit` — what you show `save_media_kit` writes your authored story: a summary, channel and region footprint, verticals, and the evidence links it was sourced from. Omitted fields are left unchanged. ```json theme={null} { "summary": "Regional lifestyle and news network reaching auto intenders across the Southeast US.", "propertyCount": 42, "channels": ["display", "ctv"], "regions": ["US"], "verticals": ["news", "lifestyle", "automotive"], "evidenceUrls": ["https://example-media-group.com/advertise/media-kit-2026.pdf"], "notes": "Extracted from the 2026 media kit; property count is an estimate." } ``` ```json theme={null} { "mediaKit": { "identity": { "brandName": "Example Media Group", "logoUrl": "https://cdn.example.com/logos/example-media-group.png", "logoBackground": "dark-bg", "membershipStatus": "AAO_MEMBER" }, "profile": { "summary": "Regional lifestyle and news network reaching auto intenders across the Southeast US.", "propertyCount": 42, "channels": ["display", "ctv"], "regions": ["US"], "verticals": ["news", "lifestyle", "automotive"], "evidenceUrls": ["https://example-media-group.com/advertise/media-kit-2026.pdf"], "notes": "Extracted from the 2026 media kit; property count is an estimate." } } } ``` `identity` is **read-only**: brand name, logo, logo background, and membership badge are resolved from your registered brand identity, and `save_media_kit` has no fields for them. **What the kit can show today, and what it can't yet.** Brand name, logo, logo background, and membership status are the only resolved-identity fields a seller's own read exposes. Your brand colours exist and are already shown to buyers and join-link visitors — but not back to you here, an asymmetry we know about rather than a design choice. Fonts, tagline, audience/reach figures, case studies, and tentpoles aren't captured anywhere yet. There is also no price list of product templates on this noun yet — `media_kit` is its planned home, but no tool writes one today, so don't expect `save_media_kit` to accept prices. ## `playbook` — how you sell `save_playbook` has two independent halves you can send together or apart: `content` (posture and packaging guidance, versioned) and `pricing` (your value-anchor facts). ```json theme={null} { "content": "## Posture\nLead with premium CTV before offering display discounts. Hold value on flagship inventory during Q4.\n\n## Packaging\nBundle CTV pre-roll with display when a brief mentions video.", "notes": "Initial playbook, drafted from the Q4 sales deck.", "pricing": { "currency": "USD", "facts": [ { "id": "ctv-flagship", "label": "CTV flagship pre-roll", "appliesWhen": "Buyer requests CTV pre-roll on flagship shows", "pricingModel": "cpm", "targetPrice": 42, "floorPrice": 32, "strength": "hard_floor", "provenance": "2026 rate card, page 4" } ] } } ``` ```json theme={null} { "playbook": { "active": { "version": 3, "content": "## Posture\nLead with premium CTV before offering display discounts. Hold value on flagship inventory during Q4.\n\n## Packaging\nBundle CTV pre-roll with display when a brief mentions video.", "notes": "Initial playbook, drafted from the Q4 sales deck.", "createdAt": "2026-07-28T15:04:00Z", "ownershipIssues": [] }, "pricing": { "currency": "USD", "facts": [ { "id": "ctv-flagship", "label": "CTV flagship pre-roll", "appliesWhen": "Buyer requests CTV pre-roll on flagship shows", "pricing": { "pricingModel": "cpm", "currency": "USD", "targetPrice": 42, "floorPrice": 32 }, "strength": "hard_floor", "provenance": "2026 rate card, page 4" } ] } }, "createdVersion": 3, "replacedVersion": 2 } ``` `ownershipIssues` names any line in the active version that restates a fact `business_rules` or `media_kit` already owns. `pricing.facts` **replaces the whole list** — a fact you don't repeat in the request is removed, the same "whole document" semantics as `content`. ## `business_rules` — what you accept `save_business_rules` also has two independent halves: `content` (your acceptance policy, versioned) and the two approval gates. ```json theme={null} { "content": "## Acceptance policy\nWe do not accept gambling, tobacco, or political advertisers. Fast-food advertisers require review before their creative goes live.", "notes": "Adds a review requirement for fast-food advertisers." } ``` ```json theme={null} { "businessRules": { "creativeApproval": "manual", "mediaBuyApproval": "manual", "policy": { "version": 5, "content": "## Acceptance policy\nWe do not accept gambling, tobacco, or political advertisers. Fast-food advertisers require review before their creative goes live.", "notes": "Adds a review requirement for fast-food advertisers.", "createdAt": "2026-07-28T15:10:00Z" } }, "createdVersion": 5, "replacedVersion": 4 } ``` ### Turning off human review Moving `creativeApproval` or `mediaBuyApproval` to `auto` needs `acknowledgeNoHumanReview: true` on the same call: ```json theme={null} { "mediaBuyApproval": "auto", "acknowledgeNoHumanReview": true } ``` Leave it out and the save fails with a validation error rather than a silent no-op: ``` Moving media buys to `auto` means nobody reviews them, and your acceptance policy is no longer consulted for media buys. Pass acknowledgeNoHumanReview: true to proceed. ``` **`auto` doesn't relax your acceptance policy — it skips it.** The gate that decides whether a media buy needs review is checked *before* the policy runs. With `mediaBuyApproval: auto`, every buy forwards and the active acceptance policy is never consulted at all — not "the policy allows it," but "the policy doesn't run." With `mediaBuyApproval: manual` and no active policy, the opposite happens: nothing pre-clears and every buy is held for you. Activating a policy is what lets the clearly-on-policy subset forward on its own while you stay in `manual`. ## Every save is create-and-activate — there's no separate activate call `playbook.content` and `business_rules.content` are versioned and immutable. Saving one **creates a new version and makes it active in the same call** — the response's `createdVersion` and `replacedVersion` tell you what happened, and there is no `activate` input or `activate_*` tool on `/mcp/v3`. A version you save has full effect immediately; there's no draft state where it exists but hasn't taken effect. Rolling back is saving the earlier content again: doing so mints a new version with that content, which becomes active. There's no "reactivate version 2" call — history is append-only and every version you can read is one you (or something writing on your behalf) actually saved. `save_playbook` and `save_business_rules` also each take an unversioned half in the same call — `pricing` on the playbook, the approval gates on business rules. When a call carries both halves, `content` is written and activated **first**. If the unversioned half then fails, the version is already live and is **not** rolled back — there is no transaction spanning the two. The error response still names `createdVersion` (and `replacedVersion`) so you know a version exists before retrying, and the retry only needs to repeat the half that failed: sending `content` again would mint a second, identical version rather than fixing anything. ## Searching version history `media_kit`, `playbook`, and `business_rules` are singletons, so `search` doesn't search *them* — there is exactly one of each, and searching "your one playbook" isn't a meaningful query. What **is** list-shaped is their version history: ```json theme={null} { "kind": "playbook_version", "query": "CTV" } ``` ```json theme={null} { "sources": ["objects"], "objects": { "kind": "playbook_version", "total": 3, "matched": 1, "returned": 1, "truncated": false, "results": [ { "version": 3, "isActive": true, "notes": "Initial playbook, drafted from the Q4 sales deck.", "createdAt": "2026-07-28T15:04:00Z" } ] } } ``` `business_rules_version` works the same way over acceptance-policy history. Omit `kind` and `search` lists every list-shaped object it knows about, `playbook_version` and `business_rules_version` included. The one-endpoint, noun-shaped surface these tools live on. The four Pages you use today, and how they map to the platform. How the pre-screen reads your policy, and the three verdicts it returns. Component, Product, and the rest of the vocabulary these nouns build on.