# What it took to ship a production remote MCP server with OAuth 2.1 > Source: > Published: 2026-08-01 19:48:50+00:00 Publishing an MCP endpoint is easy. Making it behave consistently across clients is where the work starts. We recently shipped a hosted MCP server for Minds, an evidence-grounded synthetic market research platform. The server now connects to ChatGPT, Claude, Cursor, Google Antigravity, and clients that support Streamable HTTP. Here are the implementation lessons that mattered. Our MCP client URL is: ``` https://getminds.ai/mcp ``` That URL speaks the protocol. A normal browser should instead reach an indexable setup guide. We therefore keep two explicit fields wherever a registry supports them: the remote transport URL for clients and `/mcp/setup` for humans. One early integration failed with: ``` Not Acceptable: Client must accept text/event-stream ``` The robust client request advertises both response types: ``` Accept: application/json, text/event-stream Content-Type: application/json ``` Our current endpoint successfully negotiates a JSON initialize response and returns an `Mcp-Session-Id` for the session. The initialize response points clients to OAuth protected-resource metadata. Clients that support dynamic registration can discover the flow without a copied client ID or secret. API keys remain available for environments that securely support custom bearer headers. The server currently exposes 15 tools across audiences, panels, durable studies, study drafts, summaries, method discovery, and export. Clients should inspect the live `tools/list` response rather than hard-code schemas from an old article. Our public repository documents the role of every operation, but deliberately treats the running server as the schema authority. For multi-question research, the client first calls `plan_panel_study` . A human can review the plan before `run_panel_study` starts a durable server-side run. The agent polls `get_panel_study` instead of assuming a long task finished inside one chat turn. Synthetic panels are useful for an early decision-support pass: sharpening a question, surfacing objections, comparing plausible reactions, and deciding what deserves real-respondent validation. They are not representative human fieldwork. The repository and setup guide are public: If you maintain a remote MCP server, I would be interested in the client-specific edge case that consumed the most time for you.