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

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
Planning for a deprecation or retirement	Releases & Deprecation
Handling a refused call	Troubleshooting