Skip to main content

​
Availability and compatibility

  • v3 is available only to enrolled accounts.
  • v2 remains the stable default and is not deprecated.
  • v3 is MCP-only; there is no /api/v3 REST surface.
  • The unversioned buyer and seller MCP aliases continue to resolve to stable v2.
  • Organisation accounts currently provide navigation and shared tools, not an organisation-specific noun catalog.
  • Selecting v3 in the documentation picker does not enroll an account.
get_status and switch_account work outside the cohort so a session can orient and leave an unenrolled account. No other account tools are implied by a successful connection.

​
Buyer limitations

The Buyer surface supports advertiser and campaign authoring, creative management, proposal requests, media-buy staging, and explicit campaign launch. The following gaps remain: Launching is supported, but only as a separate update to an existing campaign:
A failed launch may report a partial write because downstream execution state was attempted. Re-read before retrying.

​
Seller limitations

  • The full “test my Seller Account as a Buyer” vertical is still being completed. Use v2 test-campaign operations when the ordinary sandbox Buyer path cannot express the test.
  • Some credential, payout, approval, retry, and reassignment work intentionally remains in Pages rather than model-authored tools.
  • save_media_kit remains for compatibility but is deprecated; new clients should author Discovery Card identity through save_seller.
  • Seller delivery is seller-reported. It is not Buyer measurement and does not establish billing eligibility by itself.

​
Catalog and host differences

The runtime catalog may be narrower than the tables in these docs because of account kind, permissions, feature rollout, and MCP App visibility. Always use tools/list for the active account. After switch_account, clients should process notifications/tools/list_changed and call get_status again. A stale tool call fails with typed wrong-account guidance rather than crossing the account boundary.

​
Payload, connection, and timing limits

  • Structured responses over 200 KB are truncated as a safety backstop.
  • One MCP connection is held open for at most 30 minutes; reconnect with the existing session when the client uses sessionful MCP.
  • A single tool call is also limited to 30 minutes.
  • Deploys can close connections and eventually interrupt long in-flight calls.
  • request_proposals waits at most 30 seconds per seller and reports unsettled sellers as failures instead of waiting indefinitely.
  • Seller delivery ranges are inclusive and limited to 90 days.
Long-running work should use an asynchronous workflow where one is available instead of holding a single MCP call open.

​
Direct-client model usage

Interchange can observe API calls, server-side model calls, and Murph-hosted turns. It cannot observe the input/output token usage or model cost incurred by an external MCP client’s own model. Integrators remain responsible for that client-side budget and telemetry.

​
Choosing v2 or v3

Use v3 when:
  • the account is enrolled;
  • an account-resolved MCP surface is useful;
  • the required workflow appears in the current tool catalog; and
  • the documented preview gaps do not require a v2 continuation.
Use v2 when:
  • the integration requires a stable production contract or REST;
  • the account is not enrolled;
  • the workflow is listed as incomplete above; or
  • migration would remove a capability the integration already depends on.
No migration is required. A client may keep v2 while evaluating v3 through a separate connector.