Panels lets an AI agent create a brand-new account and workspace entirely through MCP — no visit to a registration, verification, or onboarding page. This is the enrollment MCP: a small, unauthenticated tool surface an agent uses before any Panels identity exists. Once the workspace is ready, the agent hands off to the normal, OAuth-authenticated MCP server to actually do work.
Agent-first signup is served at a dedicated endpoint, /enroll/mcp, and is off by default. Your Panels operator enables it per deployment. Until then the endpoint returns 404.

​
When to use it

Use enrollment MCP when the person you’re helping has no Panels account yet and wants their agent to set one up. Everything here happens before authentication, so the tools are deliberately narrow — they can start a signup, verify an email, accept policies, and provision a workspace, and nothing else. They cannot read or touch any existing workspace’s data. If the user already has an account, skip this entirely and connect the authenticated MCP server.

​
The flow

The agent connects to /enroll/mcp with no Authorization header and drives seven tools. enrollment_start returns an opaque enr_… capability once; every later call re-supplies it as enrollment_id (there is no ambient session).
1

Start

Call enrollment_start with the user’s email and a workspace_name. Panels creates a pending identity and emails a six-digit verification code. The result carries the enr_… capability and the required policy versions — store the capability, it is shown only once and never echoed again.
2

Get the code

The user retrieves the six-digit code from their inbox and gives it to the agent. An email-capable agent may read it directly from the inbox — but only after the user explicitly approves that access for this signup. See the fallback below if the agent can’t read email.
3

Verify

Call enrollment_verify with the capability and the code. On success the enrollment becomes verified.
4

Accept policies

Call enrollment_accept_policies with the exact terms_version and privacy_version from the start result. This is an explicit, recorded acceptance — the agent should surface the policy versions to the user first.
5

Complete

Call enrollment_complete. Panels provisions the workspace, an owner membership, and a starter project, and returns {status: "ready", workspace_id, project_id}. Calling it again is safe — it returns the same ids and creates nothing new.
enrollment_status reports the current state at any point, enrollment_resend re-sends the code, and enrollment_cancel abandons an in-flight signup. The verification email contains both the six-digit code and a verification link — the link is the identity provider’s standard fallback for people who would rather click than type.
For the agent-first journey, give the agent the code — don’t click the link. The link verifies your email directly with the identity provider and consumes the one-time code, after which the agent’s enrollment_verify step can no longer complete the Panels enrollment. The two ways to hand over the code — an email-capable agent reading it (with your approval) or you pasting it — both reach the same verified state; the email link does not.
If the code was consumed (for example because the link was clicked), the agent can call enrollment_resend to send a fresh code and continue.

​
Security boundary

Enrollment MCP is unauthenticated because there is no identity or tenant token yet — so it is built to give an agent no authority beyond signing up:
  • No workspace reach. The seven tools are the entire surface. There is no path from /enroll/mcp into any tenant’s data, even for an existing workspace.
  • No credentials are ever returned. Completion yields only workspace_id and project_id — never a session, password, OAuth code, access token, or refresh token. The verification code is an ephemeral input; it is never stored, logged, or echoed back.
  • Existing emails are indistinguishable. Starting a signup for an email that already has an account returns the same shape and timing as a fresh one, so the surface cannot be used to enumerate who has a Panels account.
  • Abuse-bounded. Rate limits, a durable per-enrollment attempt budget, and a fail-closed production boot gate apply — an operator turns the surface on deliberately.

​
Handoff to normal MCP authorization

Enrollment ends the moment enrollment_complete returns ready. The new user does not get a token from the signup flow. To start working, they authenticate separately:
  1. Point an MCP client at the authenticated workspace endpoint (/mcp) — see MCP server.
  2. The client runs the standard OAuth consent flow; the user signs in with the account they just created and approves scopes.
This is by design: account creation and authorization stay separate, so the pre-auth enrollment surface never mints a credential. The OAuth consent UI a host opens after signup is expected and is not something the agent replaces.

​
Supported clients

Any MCP client that speaks Streamable HTTP can drive enrollment; it must allow connecting to an endpoint without an OAuth/bearer credential, since the surface is deliberately pre-auth.
Panels does not certify unsupported MCP clients or email providers, and does not list Panels in third-party connector directories. A host that mandates OAuth before it will connect to any MCP endpoint cannot be used for the pre-auth enrollment surface.

​
Next

Connect the authenticated MCP server

Once the workspace is ready, sign in with the new account and start building.