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

Copy-paste prompt

Paste this into your coding agent. Your audit adds what it observed for this check:

Verify

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