Skip to main content
There is no separate merchandising document. Merchandising is what your storefront does — the Merchandising Agent selling on your behalf — not a thing you save. Three nouns steer it, split by what kind of fact each one holds: The Page names and read tools now use the same three nouns. Selling Terms is retired: structured prices and floors moved to Playbook, while approval gates moved to Business Rules. Business Profile became Media Kit and Merchandising Rules became Playbook. Your saved configuration and version history do not move or reset. In chat and any MCP Apps host, get_media_kit, get_playbook, and get_business_rules open the portable Pages.
/mcp/v3 remains a gated preview. The get and save_* examples below apply only to that surface; the get_media_kit, get_playbook, and get_business_rules Pages are available through the current seller MCP surface.

One fact, one owner

Playbook instruction content cannot duplicate structured Playbook pricing, Buyer Discounts, Media Kit facts, or Business Rules. It may refer to those facts without restating them. A conflicting version is rejected on save rather than left for the agent to reconcile later. Business Rules separates two decisions: approval gates decide whether human review runs, and the acceptance policy classifies what is on policy when review is enabled. With mediaBuyApproval: manual and no active policy, every media buy is held for review. Media Kit and Playbook guide what the agent presents and how it sells; neither controls the review gate.

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.
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 buyers see

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.
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).
ownershipIssues identifies any line in the active guidance that duplicates structured Playbook pricing, Buyer Discounts, Media Kit facts, or Business Rules. 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.

Turning off human review

Moving creativeApproval or mediaBuyApproval to auto needs acknowledgeNoHumanReview: true on the same call:
Leave it out and the save fails with a validation error rather than a silent no-op:
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:
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.

v3 Agent Surface

The one-endpoint, noun-shaped surface these tools live on.

Merchandising

The three Pages you use today, and how they map to the platform.

Acceptance policy

How the pre-screen reads your policy, and the three verdicts it returns.

Glossary

Component, Product, and the rest of the vocabulary these nouns build on.