Skip to content

v1.2.0: Season Pass

Choose a tag to compare

@github-actions github-actions released this 29 Jun 13:46
1e3a5ce

Up at the top, the view goes on forever. Ridge after ridge, lift after lift, all of it suddenly within reach thanks to the new season pass 🏔️

v1.1.0 got apps onto the lift. v1.2.0 is about where they're allowed to ride, this release makes OAuth a first-class citizen, with pre-cut trails to the major identity providers. We've also refreshed the docs so you can explore the whole resort with ease.

  • Branded OAuth providers: WorkOS, Auth0, Clerk, Stytch, and Descope, each wired up around Dynamic Client Registration
  • Refreshed docs: a reworked guide that's easy to navigate
  • One runtime: views now emit a single MCP Apps resource, retiring the separate OpenAI Apps path
  • DevTools as WebMCP tools: the model can now drive the DevTools directly through the browser's WebMCP API

Branded OAuth providers

Until now, wiring identity into a Skybridge server meant doing the OAuth legwork by hand. This release makes auth a first-class concern.

Five branded providers ship ready for Dynamic Client Registration: Auth0, Clerk, Descope, Stytch, and WorkOS. Point one at the IdP and sign-in works out of the box. Auth is now a first-class field on McpServer, so it's declared once and the SDK threads it through the rest of the stack.

import { McpServer, descopeProvider } from "skybridge/server";

const server = new McpServer(
  { name: "my-app", version: "0.0.1" },
  { capabilities: {} },
  {
    oauth: await descopeProvider({
      // e.g. https://api.descope.com/v1/apps/agentic/{PROJECT_ID}/{MCP_SERVER_ID}
      url: env.DESCOPE_MCP_SERVER_URL, 
    }),
  },
);

For a setup without a branded provider, customProvider accepts any standards-compliant OAuth authorization server and Skybridge treats it like a built-in one.

import { McpServer, customProvider } from "skybridge/server";

const server = new McpServer(
  { name: "my-app", version: "0.0.1" },
  { capabilities: {} },
  {
    oauth: await customProvider({
      issuer: "https://issuer.example.com",
      // ...authorization server details
    }),
  },
);

Paired with the mixed-auth support from the previous release, a server now has full control over access: some tools open to everyone, the rest gated behind whichever provider is configured.

Refreshed docs

The docs are organized as a journey. You begin by learning what MCP Apps are, what problem Skybridge solves and how to get started, then move into Build guides that teach each piece of an app in the order you'd actually write it, branch into Guides for cross-cutting topics like auth, files, and UX, and finish in Test and Ship for running and deploying.

An API Reference sits alongside for exact lookups. Every page reads the same way: it names the problem, shows one complete worked example, then walks through that example piece by piece, so you learn the concept and see the real code at once.

Explore the new docs

Unifying to a single runtime

The OpenAI Apps resource has been retired in favour of the MCP App one. This was made possible by OpenAI's support of MCP Apps: views now always emit a single MCP Apps resource, regardless of host. The change is internal to Skybridge and has no impact on the public API.

Note: For the change to take effect and stop OpenAI from using the old resource, you'll need to resubmit a new version of your app once you've upgraded to Skybridge 1.2 and deployed the new server to production. The change is backward compatible, so there's no risk of breaking anything in your live traffic.

DevTools as WebMCP tools

The DevTools interface is now exposed as WebMCP tools, which means the model can talk to the DevTools the same way it talks to any other view. Inspecting and driving an app during development stops being a manual click-through and becomes something the model can handle on its own.

Learn more about it in Code with Fred #7


Changes