> For the complete documentation index, see [llms.txt](https://docs.mediafier.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediafier.ai/connect/protocol-changes.md).

# Protocol Changes

Dated record of changes to how the Mediafier MCP endpoint behaves that an integration may need to act on: what changed, who is affected, and what to do.

> **One entry per change your integration might notice.** Each entry says what changed, who is affected, and what to do. An entry is added on the day the change is live on `https://mcp.mediafier.ai/mcp`, not before, so every entry here describes behavior you can observe today.

## How to read this page

* **Newest first, dated by production.** The date is when the change reached the production endpoint.
* **Only changes you can observe.** Internal changes that leave requests and responses the same are not listed.
* **Upcoming changes are not listed.** A change that removes or retires something follows [Releases & Deprecation](/connect/release-and-deprecation.md): the notice travels with the affected response.
* **The live response still wins.** If this page and a response disagree, the response is current. Authenticated discovery (`tools/list`, `resources/list`) is the authority for what your organization can call.

## 2026-09-23

### The `initialize` response no longer claims list-change notifications

* **What changed:** the capabilities in the `initialize` response are now `"tools": {}` and `"resources": {}`. They previously included `"listChanged": true`, which promises a notification whenever the tool or resource list changes. The endpoint does not send those notifications, so it no longer claims to.
* **Who is affected:** clients that waited for a list-change notification before refreshing their tool or resource list. None ever arrived, so nothing you received has changed; the advertisement now matches what the endpoint does.
* **What to do:** call `tools/list` or `resources/list` again when you need a current list, for example after a new server is installed for your organization or when you reconnect.

### Browser clients can send `Mcp-Method` and `Mcp-Name`, and read `Retry-After`

* **What changed:** the endpoint's cross-origin rules now allow the `Mcp-Method` and `Mcp-Name` request headers, and a refused request's `Retry-After` header now reaches the client and is readable from browser code.
* **Who is affected:** browser-based clients. A browser previously blocked requests carrying those two headers before they were sent, and could not see how long to wait after being refused. Server-side clients see no change.
* **What to do:** nothing required. When a response carries `Retry-After`, wait at least that many seconds before retrying.

### Rate limits also apply to each tool

* **What changed:** calls are limited per tool as well as across a server's tools. A burst of calls to one tool can be refused even while your organization's overall use of that server is within its limit.
* **Who is affected:** integrations that call a single tool in tight loops. Typical interactive use does not reach the per-tool limit.
* **What to do:** treat a rate-limit refusal as a signal to back off and retry, honoring `Retry-After` when present. Batch or pace repeated calls to the same tool. See [Troubleshooting](/connect/troubleshooting.md).

## 2026-09-21

### A public server card describes the endpoint

* **What changed:** `https://mcp.mediafier.ai/.well-known/mcp-server` now returns a server card: the endpoint, its transport, the MCP protocol versions it accepts, and where to find the authorization metadata.
* **What it is not:** the card is Mediafier's own format. It is not part of the MCP specification, and MCP clients do not read it automatically.
* **Who is affected:** tooling you write, or a registry, that chooses to read it. Clients that connect with the endpoint URL directly see no change.
* **What to do:** nothing required. If your own tooling reads the card, it can take the accepted protocol versions from there rather than hard-coding them.

### Repeated standard MCP headers, and oversized MCP headers, are refused

* **What changed:** a request is refused before it is processed if it sends `Mcp-Protocol-Version`, `Mcp-Session-Id`, `Mcp-Method` or `Mcp-Name` more than once, or sends one of the first three with several values in one field (how some HTTP stacks merge a repeated header). A request whose `Mcp-*` headers are unusually many or unusually large is refused too. The error names the header where one is at fault and includes a trace identifier.
* **Not affected:** other `Mcp-*` headers sent more than once are combined into one value, as HTTP allows, and forwarded.
* **Who is affected:** integrations that set one of those four headers in two places, for example as a client default and again per request. Well-formed requests see no change.
* **What to do:** send each of those four headers once, with a single value. If you are refused, fix the header named in the error, and include the trace identifier if you contact support.

## Where to go next

| If you're…                                | Read next                                                     |
| ----------------------------------------- | ------------------------------------------------------------- |
| Checking whether your client is supported | [Compatibility](/connect/compatibility.md)                    |
| Planning for a deprecation or retirement  | [Releases & Deprecation](/connect/release-and-deprecation.md) |
| Handling a refused call                   | [Troubleshooting](/connect/troubleshooting.md)                |