> ## 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 Preview Limitations

> Enrollment, compatibility, lifecycle, and operational limits of the v3 preview.

## 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:

| Capability                           | Current behavior                                                                                 |
| ------------------------------------ | ------------------------------------------------------------------------------------------------ |
| Campaign cancellation                | `desiredPhase: "canceled"` is not implemented; use v2                                            |
| Campaign unarchive                   | `isArchived: false` is not implemented; use v2                                                   |
| Campaign autonomy                    | Accepted for forward compatibility but not persisted                                             |
| Clear campaign brief or flight       | `null` is currently a no-op, not a clear operation                                               |
| Proposal evaluation policy           | Instructions and policy fields are recorded but not applied to ranking                           |
| Media-buy creation flight            | Stage first, then update the draft by `mediaBuyId`                                               |
| Media-buy top-level budget           | Use `products[].budget` on direct creation                                                       |
| Buyer media-buy archive state        | Reads currently project `isArchived: false`; use v2 when authoritative archive state is required |
| Proposal evidence on media-buy reads | Preserve `proposalSource` from the acceptance response; later Buyer reads do not include it      |
| Tracked campaign adoption            | Use the existing v2 adopt or duplicate workflow                                                  |

Launching is supported, but only as a separate update to an existing campaign:

```json theme={null}
{
  "campaignId": "CAMPAIGN_ID",
  "expectedRevision": 4,
  "desiredPhase": "active",
  "idempotencyKey": "launch-attempt-v1"
}
```

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.