What happened
Clerk’s GitHub release for @clerk/mcp-tools v0.9.0, published on November 6, adds a browser-session tool and changes to scope authorization. The new createBrowserSessionTool is exported from @clerk/mcp-tools/create-browser-session. It creates a one-time link that opens an application signed in as the user represented by the MCP token. The corresponding createBrowserSession function accepts a new restricted option, enabled by default, and an optional organizationId.
A restricted link starts a session in which Clerk’s Frontend API refuses several writes and transitions: touching the session, switching the active session or organization, signing out, writing to the user’s profile or organizations, reverification, and OAuth consent or approval. Refreshing the session’s own token is the listed exception. If organizationId is set, that organization is the only one the restricted session can use. The application’s own backend still sees an ordinary signed-in session, a distinction teams must account for when designing authorization.
Clerk says it must confirm the restriction in its response before returning a link. If it does not, the tool returns no link, uses best-effort revocation of the newly created session link, and reports the restricted_not_applied error code. The same confirmation and failure behavior applies when a requested organization is not confirmed. If the user does not belong to the organization, or an organization is required but none applies, the error is organization_rejected. Passing restricted: false requests an ordinary session.
The release also exports requireAdditionalScopes from @clerk/mcp-tools/server and @clerk/mcp-tools/next. It builds the MCP SDK scopeChallenge registration option from a tool’s required scopes, allowing a tool to trigger an additional-scope challenge when its token lacks permission. This flow is supported by MCP SDK 2.1 or later. On SDK 2.0, a missing scope reaches the tool instead of triggering the challenge; the tool logs one Clerk warning per process recommending an upgrade. The release also tightens the isClerkAuthInfo type guard and validates that fetch is a function when feedback tools are created and called.
What the archive adds
New Runtime’s earlier coverage of Agno 3.1.9 described browser-origin access to an existing MCP server, a related but separate integration surface: Agno 3.1.9 adds an HTTP MCP Tool Runner and browser-origin access to the AgentOS MCP server. Clerk’s release is a new event, not a restatement: it focuses on session restrictions and scope escalation rather than browser-origin access.
Trend signal
This release supports the assumption that enterprises will adopt scoped, expiring agent credentials rather than rely on shared keys or borrowed user sessions. Clerk’s default-restricted one-time session link is a concrete credential boundary, although the release does not establish enterprise adoption. Delegated agent identity.
Why it matters
A browser session that is signed in as a real user can otherwise inherit actions that are wider than an agent’s task requires. Clerk’s default restriction offers a starting point for reducing what the Frontend API will accept from a session opened through an agent-generated link. The step-up mechanism also gives a tool a way to request more authority when it reaches a protected operation, rather than giving every tool broad scopes at the start.
These are useful primitives, not a complete authorization design. The release explicitly says the app’s backend still sees an ordinary signed-in session, so a team must check its own server-side authorization paths rather than assume the Frontend API restrictions apply everywhere. Teams also need to ensure they run a compatible MCP SDK version to get the challenge behavior. The practical value is in making a narrower, inspectable default easier to implement, while keeping application-level policy and testing with the builder.
What happens next
- More Clerk-backed MCP integrations will adopt restricted browser sessions as their default handoff. (6 months, 60%). Watch for: examples or documentation using
createBrowserSessionToolwith its default restriction enabled.
Limits and uncertainty
Clerk’s release notes describe the intended API behavior but do not provide independent testing, security evaluation, adoption numbers, or performance measurements. They do not quantify how often Clerk confirms restrictions or organizations, nor the operational reliability of best-effort link revocation. The release also does not explain how a particular application backend should enforce the same limits; it says that backend requests still see an ordinary signed-in session. Teams should verify behavior in their own frontend and server flows, and confirm their MCP SDK version before relying on step-up challenges.
Skill to build now
In a test Clerk application, create a restricted browser session for a test user and attempt each class of blocked action listed in the release: sign-out, organization switching, profile writes, and OAuth approval. Then exercise the same flows through your own backend, because Clerk says it sees an ordinary signed-in session. If your MCP server uses scope challenges, test both an insufficient-scope response on SDK 2.1+ and the fallback error path on SDK 2.0.
Reader takeaway
Clerk mcp-tools 0.9.0 gives MCP builders two practical authorization primitives: a one-time, restricted browser session by default and a way for tools to request additional scopes. Treat them as boundaries to test, not as a substitute for backend authorization; the server side still sees an ordinary signed-in user.