vercel-mcp-overview

Summary Add Antigravity to the client setup table in README (it was not listed among supported clients). Add with OAuth and Bearer-token configuration, verification steps, and troubleshooting for the common 406 Not Acceptable handshake failure. Motivation Antigravity uses Streamable HTTP with its own default header. Vercel MCP is strict about content negotiation; users who override or misplace auth ( vs ) see opaque 406 errors with no doc guidance. Addresses #1 Test plan [ ] JSON examples validate in Antigravity [ ] Link from README resolves to [ ] Consider mirroring this section on

Summary rejects many MCP HTTP clients with 406 Not Acceptable during the Streamable HTTP handshake. The failure mode is opaque (generic 406, no guidance on required headers), and the public docs do not describe the exact / negotiation the server enforces. This makes third-party clients (e.g. Google Antigravity) appear "bricked" even when configuration is otherwise correct. Environment Server: (Vercel MCP, Streamable HTTP transport) Client: Google Antigravity (remote HTTP MCP) Auth: Bearer token via (remote servers; Antigravity schema rejects top-level for non-local MCP) What happens 1. Vercel MCP enforces strict content negotiation on Streamable HTTP requests. If does not match what the server expects, it returns 406 Not Acceptable instead of falling back to JSON-only responses. 2. Antigravity injects its own header internally, e.g.: 3. When users also set in MCP config , Antigravity's client and the user override can collide. Vercel sees a non-conforming value and the handshake dies with 406. 4. Antigravity's config schema only allows for local MCP servers; remote servers must use for . That is reasonable, but combined with (2)–(3) it is easy to misconfigure without any doc pointing at the required header set. 5. Vercel's setup docs () list one-click installs per client but do not document: Required values for Streamable HTTP / JSON-RPC POST Whether is accepted How custom interact with client-default headers Example for debugging negotiation without a full IDE Expected Document required request headers for Streamable HTTP (at minimum and ) on the Vercel MCP docs page. Return a actionable error body on 406 (e.g. which values are required, link to docs). Where possible, accept common client combinations that still satisfy the MCP Streamable HTTP spec (e.g. tolerate when is also present), or clearly state that only is supported. List Antigravity (or generic "custom HTTP MCP client with configurable headers") in troubleshooting if approval is required. Actual Connection fails with 406 Not Acceptable during MCP handshake. Error message does not explain header requirements. Trial-and-error across / / auth placement is required. Working configuration (Antigravity) The only combination found to satisfy both Antigravity and Vercel MCP: Notably: do not set in (let Antigravity supply it, or ensure it matches Vercel's requirements exactly). Use for auth, not top-level . Suggested improvements 1. Docs: Add a "Streamable HTTP / troubleshooting" section with: Required headers table example for (with and without Bearer token) Note for clients that inject default 2. Server: On 406, respond with JSON explaining required media types. 3. Interoperability:** Review whether strict rejection of is necessary vs. spec-compliant . Related MCP Streamable HTTP transport: Similar 406 reports elsewhere (missing or wrong ): ,