# Self-Service MCP Sign-In Needed a Developer Experience Fix > Connecting Cursor, VS Code, or Claude Code to ZopNight used to assume the setup work was already done: an account, an organization, and an administrator who had separately switched MCP on before any… Source: https://zop.dev/resources/blogs/mcp-sign-in-can-now-create-your-organization-too Published: 2026-09-30 · Author: riya-mittal · Tags: platform-engineering, self-service, mcp --- Connecting Cursor, VS Code, or Claude Code to ZopNight used to assume the setup work was already done: an account, an organization, and an administrator who had separately switched MCP on before any tool call would actually succeed. None of that assumption survives first contact with someone brand new to the product. A person can now sign up directly from the tool's own [self-service sign-in link](https://zop.dev/resources/blogs/oauth-consent-for-ai-assistants-per-assistant-grants), with no existing account or organization required. ZopNight creates their organization with MCP already switched on, and a Continue to zopdev button carries them straight into ZopNight or ZopDay. The permission screen itself picks up a one-click Full [write access](https://zop.dev/resources/blogs/read-only-mcp-servers-cloud-infrastructure-ai) option. ## The Full Sequence, Not Just the Happy Click The complete journey is: open the MCP client, sign up or sign in, get an organization, hit Authorize, click Continue to zopdev, land in the product. Each step in that chain had to be checked against a visitor who might be arriving with nothing already set up. Architecture diagram A visitor who reaches the consent screen while signed out, or who clicks Switch account partway through, is routed through the [same shared sign-in page](https://zop.dev/resources/blogs/centralized-sign-in-remembers-your-product-per-email) everyone else uses, which then sends them straight back to consent before any of that sign-in page's own normal routing logic has a chance to apply. Reusing the existing page, rather than building a parallel one just for this path, is what keeps the whole flow from quietly diverging from how sign-in behaves everywhere else in the product. ## A New Org Has to Arrive With MCP Already On A visitor who reaches consent with literally no organization at all gets routed into onboarding, which creates one named after them, something like their name followed by Org, and then returns them to consent to continue. The part that matters is what happens inside that specific onboarding path and nowhere else: it writes mcp_enabled as true directly, as part of the exact same organization-defaults update call that creates the org in the first place. A failure during that write shows a toast and logs a distinct failure event, rather than silently leaving a half-configured organization behind. The separate, older path for creating an organization from the user menu is left completely untouched, since that path was never meant to assume anything about MCP at all. ## One Signal Decides the Whole Journey Exactly one thing tells the system that a given visitor is moving through this MCP-specific path rather than an ordinary sign-in: the calling page's own returnTo parameter. Nothing else, no separate flag, no distinct URL structure, no special session state, carries that information. That narrowness is deliberate. A shared sign-in page and a shared onboarding flow can stay genuinely shared, serving every entry point that reuses them, specifically because the one signal that needs to vary behavior is isolated to a single, well-defined parameter rather than scattered across several places that could each drift out of sync with each other over time. Clicking Continue to zopdev opens a product picker with its own switch flag set, and a sign-in that happens through this specific journey deliberately no longer auto-records zopnight as the chosen product the way an ordinary sign-in would, since the entire purpose of showing the picker here is to let the person make that choice for themselves. ## A Checkbox That Actually Lists What It Grants The new Full write access toggle checks every available write policy across both products in one motion, but it doesn't hide the consequence behind a single opaque checkbox. The resulting summary of exactly what's being granted renders as a collapsible list a person can expand and read before approving anything. This works when an administrator wants to grant broad access quickly and still see precisely what that access covers. It changes nothing about what actually gets enforced afterward, since every real tool call remains bounded by the organization's own role-based permissions and by [whatever MCP write tier](https://zop.dev/resources/blogs/mcp-write-tools-cloud-estate-three-tier-gating) that specific organization is on, regardless of what the consent screen displayed. ## A Better Developer Experience, Scoped to the Frontend Every part of this change lives in the frontend application alone. No backend service changed, the gateway didn't change, the authentication service didn't change, and no database schema moved. That scoping has a direct consequence worth stating plainly: an organization that already exists today, with MCP switched off, still needs an administrator to go turn it on by hand. This release only changes what happens the moment a brand-new organization gets created through this specific path. It doesn't reach backward to fix anything for an organization that was already there before it shipped.