# Fix: an unsatisfiable Accept draws a 406 rather than an unasked-for type

> Web-audit fix skill for the `mcp-accept-unsatisfiable` check (MCP, SHOULD).

## Goal

Refuse an Accept you cannot satisfy with 406, never a 200 carrying a type the client did not request.

## Fix

When the request `Accept` allows neither `application/json` nor `text/event-stream`, refuse
with `406 Not Acceptable` before any JSON-RPC parsing runs. Those two media types are the
whole of what the streamable-HTTP transport is defined over, so an `Accept` naming neither
cannot be served.
The failure this check looks for is a server that ignores `Accept` and answers with its one
representation under a success status, leaving the caller to sniff the body to find out the
negotiation never happened. Worse is a `200` that echoes the requested type back in
`Content-Type` while carrying a JSON-RPC body: the caller routes on your label and the parse
fails downstream.
Do the check at the transport edge and keep the body plain text, so no client mistakes the
refusal for a JSON-RPC error envelope.

## Resources

- [RFC 9110 section 15.5.7 (406 Not Acceptable)](https://www.rfc-editor.org/rfc/rfc9110#name-406-not-acceptable)
- [MCP transports](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports)

## Copy-paste prompt

Paste this into your coding agent. [Your audit](https://anc.dev/audit) adds what it observed for this check:

```text
Goal: Refuse an Accept you cannot satisfy with 406, never a 200 carrying a type the client did not request
Fix: When the request `Accept` allows neither `application/json` nor `text/event-stream`, refuse with `406 Not Acceptable` before any JSON-RPC parsing runs. Those two media types are the whole of what the streamable-HTTP transport is defined over, so an `Accept` naming neither cannot be served. The failure this check looks for is a server that ignores `Accept` and answers with its one representation under a success status, leaving the caller to sniff the body to find out the negotiation never happened. Worse is a `200` that echoes the requested type back in `Content-Type` while carrying a JSON-RPC body: the caller routes on your label and the parse fails downstream. Do the check at the transport edge and keep the body plain text, so no client mistakes the refusal for a JSON-RPC error envelope.
Skill: https://anc.dev/fix/mcp-accept-unsatisfiable
Docs: https://www.rfc-editor.org/rfc/rfc9110#name-406-not-acceptable, https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
```

## Verify

Re-run the audit at [https://anc.dev/audit](https://anc.dev/audit) or call the `audit_website` MCP tool; the `mcp-accept-unsatisfiable` check should report `pass`.