zuplo 6.70.53 → 6.70.55

package/docs/mcp-gateway/code-config/multi-upstream.mdx

@@ -0,0 +1,293 @@
+---
+title: "Add multiple upstream MCP servers"
+sidebar_label: "Multi-upstream"
+description:
+  Front many upstream MCP servers from one Zuplo project. Share a single OAuth
+  policy across every route, add one token exchange policy per upstream, and let
+  each user maintain independent per-upstream connections.
+---
+
+A single Zuplo deployment can front any number of upstream MCP servers. One
+OAuth policy authenticates inbound MCP clients across every route; one
+`mcp-token-exchange-inbound` policy lives per upstream; one route per upstream
+wires them together.
+
+This page is a worked example: a single gateway project that exposes Linear and
+Stripe as two separate MCP endpoints, with the full `zuplo.jsonc`,
+`policies.json`, `routes.oas.json`, and runtime-init files you can copy into
+your own project.
+
+## The pattern
+
+Three rules form the pattern:
+
+1. **One MCP OAuth policy, project-wide.** The gateway allows exactly one MCP
+   OAuth policy per project, regardless of which
+   [IdP wrapper](../auth/overview.mdx#identity-providers) you pick. Every MCP
+   route attaches the same policy.
+2. **One `mcp-token-exchange-*` policy per upstream.** Each upstream MCP server
+   gets its own policy with its own `displayName`, `authMode`, `scopes`, and
+   optional `protectedResourceMetadataUrl`. The policy's `id` (or the `id`
+   inferred from its name) identifies the upstream — pick it once and don't
+   change it.
+3. **One `/mcp/<slug>` route per upstream.** Each route uses
+   [`McpProxyHandler`](./mcp-proxy-handler.mdx) with the upstream URL as
+   `rewritePattern`, and lists the shared OAuth policy plus the matching token
+   exchange policy in its inbound chain.
+
+A typical path convention is `/mcp/<provider>-v<n>`. The `-v<n>` suffix lets you
+publish a v2 alongside a v1 without breaking existing client configs.
+
+## Worked example: Linear and Stripe
+
+The configuration below exposes two upstream MCP servers — Linear and Stripe —
+behind one Auth0-protected gateway. Each user authenticates once to the gateway,
+then connects to Linear and Stripe independently the first time they call each.
+
+### `zuplo.jsonc`
+
+```jsonc
+{
+  "version": 1,
+  "compatibilityDate": "2026-03-01",
+}
+```
+
+### `modules/zuplo.runtime.ts`
+
+```ts
+import { RuntimeExtensions } from "@zuplo/runtime";
+import { McpGatewayPlugin } from "@zuplo/runtime/mcp-gateway";
+
+export function runtimeInit(runtime: RuntimeExtensions) {
+  runtime.addPlugin(new McpGatewayPlugin());
+}
+```
+
+### `config/policies.json`
+
+```jsonc
+{
+  "policies": [
+    {
+      "name": "auth0-managed-oauth",
+      "policyType": "mcp-auth0-oauth-inbound",
+      "handler": {
+        "module": "$import(@zuplo/runtime/mcp-gateway)",
+        "export": "McpAuth0OAuthInboundPolicy",
+        "options": {
+          "auth0Domain": "$env(AUTH0_DOMAIN)",
+          "clientId": "$env(AUTH0_CLIENT_ID)",
+          "clientSecret": "$env(AUTH0_CLIENT_SECRET)",
+        },
+      },
+    },
+    {
+      "name": "mcp-token-exchange-linear",
+      "policyType": "mcp-token-exchange-inbound",
+      "handler": {
+        "module": "$import(@zuplo/runtime/mcp-gateway)",
+        "export": "McpTokenExchangeInboundPolicy",
+        "options": {
+          "displayName": "Linear",
+          "summary": "Linear MCP upstream, per-user OAuth.",
+          "protectedResourceMetadataUrl": "https://mcp.linear.app/.well-known/oauth-protected-resource",
+          "authMode": "user-oauth",
+          "scopes": [],
+          "clientRegistration": { "mode": "auto" },
+        },
+      },
+    },
+    {
+      "name": "mcp-token-exchange-stripe",
+      "policyType": "mcp-token-exchange-inbound",
+      "handler": {
+        "module": "$import(@zuplo/runtime/mcp-gateway)",
+        "export": "McpTokenExchangeInboundPolicy",
+        "options": {
+          "displayName": "Stripe",
+          "summary": "Stripe MCP upstream, per-user OAuth.",
+          "authMode": "user-oauth",
+          "scopes": ["mcp"],
+          "clientRegistration": { "mode": "auto" },
+        },
+      },
+    },
+  ],
+}
+```
+
+A few notes on what's set per upstream:
+
+- **`protectedResourceMetadataUrl`** is explicit for Linear because Linear
+  publishes its PRM at the root well-known path
+  (`/.well-known/oauth-protected-resource`) instead of the per-route default
+  (`/.well-known/oauth-protected-resource/mcp`). For Stripe the default works,
+  so the option is omitted.
+- **`scopes: []`** for Linear means the gateway falls back to the upstream's
+  `WWW-Authenticate` `scope` value, then to the PRM's `scopes_supported`, then
+  to no scope parameter. For Stripe the explicit `["mcp"]` is what the provider
+  expects.
+- **`clientRegistration: { mode: "auto" }`** lets the gateway register a client
+  with each upstream on demand using OIDC Client ID Metadata Document discovery
+  first, then RFC 7591 Dynamic Client Registration as a fallback. No client
+  credentials need to live in source control.
+
+### `config/routes.oas.json`
+
+```jsonc
+{
+  "openapi": "3.1.0",
+  "info": { "title": "MCP Gateway", "version": "0.1.0" },
+  "paths": {
+    "/mcp/linear-v1": {
+      "get,post": {
+        "operationId": "linear-mcp-server",
+        "summary": "Linear MCP Proxy",
+        "x-zuplo-route": {
+          "corsPolicy": "none",
+          "handler": {
+            "module": "$import(@zuplo/runtime/mcp-gateway)",
+            "export": "McpProxyHandler",
+            "options": { "rewritePattern": "https://mcp.linear.app/mcp" },
+          },
+          "policies": {
+            "inbound": ["auth0-managed-oauth", "mcp-token-exchange-linear"],
+          },
+        },
+      },
+    },
+    "/mcp/stripe-v1": {
+      "get,post": {
+        "operationId": "stripe-mcp-server",
+        "summary": "Stripe MCP Proxy",
+        "x-zuplo-route": {
+          "corsPolicy": "none",
+          "handler": {
+            "module": "$import(@zuplo/runtime/mcp-gateway)",
+            "export": "McpProxyHandler",
+            "options": { "rewritePattern": "https://mcp.stripe.com/mcp" },
+          },
+          "policies": {
+            "inbound": ["auth0-managed-oauth", "mcp-token-exchange-stripe"],
+          },
+        },
+      },
+    },
+  },
+}
+```
+
+Once deployed (or running locally via `zuplo dev`), this gives clients two MCP
+server URLs to add to their config:
+
+- `https://<your-gateway>/mcp/linear-v1`
+- `https://<your-gateway>/mcp/stripe-v1`
+
+Both authenticate against the same Auth0 tenant; both produce one set of
+analytics events distinguishable by `virtualServerName` and
+`upstreamServerName`.
+
+## What each user sees on first connect
+
+A user only signs in to the gateway once. From there, each upstream needs its
+own one-time connect:
+
+- The first time the user calls `/mcp/linear-v1`, the client opens a browser to
+  authorize Linear. The next call succeeds.
+- Calling `/mcp/stripe-v1` for the first time produces a separate browser prompt
+  for Stripe. Authorizing Linear doesn't grant access to Stripe.
+
+Each user's connection to each upstream is independent — one user authorizing
+Linear has no effect on any other user.
+
+## Adding a per-route capability filter
+
+To curate the tools a specific upstream exposes — say, restrict Linear to four
+read tools — add a `mcp-capability-filter-inbound` policy and attach it to one
+route's inbound chain:
+
+```jsonc
+// config/policies.json — add to the policies array
+{
+  "name": "filter-linear-read-only",
+  "policyType": "mcp-capability-filter-inbound",
+  "handler": {
+    "module": "$import(@zuplo/runtime/mcp-gateway)",
+    "export": "McpCapabilityFilterInboundPolicy",
+    "options": {
+      "tools": ["list_issues", "get_issue", "list_projects", "list_teams"],
+    },
+  },
+}
+```
+
+Then update the Linear route's policy chain so the filter runs **after** the
+token exchange policy:
+
+```jsonc
+"/mcp/linear-v1": {
+  "get,post": {
+    "operationId": "linear-mcp-server",
+    "x-zuplo-route": {
+      "policies": {
+        "inbound": [
+          "auth0-managed-oauth",
+          "mcp-token-exchange-linear",
+          "filter-linear-read-only"
+        ]
+      }
+    }
+  }
+}
+```
+
+Only the four named tools appear in `tools/list` responses on `/mcp/linear-v1`.
+Any `tools/call` for an unlisted tool returns a JSON-RPC `MethodNotFound` error
+before the request reaches the upstream. The Stripe route is unaffected —
+capability filters are per-route.
+
+## Path and id conventions
+
+The corp dogfood deployment uses these conventions, and they generalize well:
+
+- **Route path**: `/mcp/<provider>-v<n>` — e.g., `/mcp/linear-v1`,
+  `/mcp/stripe-v1`, `/mcp/notion-v1`.
+- **`operationId`**: `<provider>-mcp-server` — e.g., `linear-mcp-server`,
+  `stripe-mcp-server`.
+- **Token-exchange policy name**: `mcp-token-exchange-<provider>` — the
+  `<provider>` portion is what becomes the upstream `id` (and the
+  `upstreamServerName` in analytics).
+- **OAuth policy name**: pick one and reuse it; `auth0-managed-oauth` or
+  `oidc-managed-oauth` are clear choices.
+
+The `-v<n>` suffix on the route path matters more than it looks: it gives you a
+clean upgrade path when an upstream provider releases a new MCP server URL with
+breaking changes. Add a new `/mcp/linear-v2` route with a new token exchange
+policy (and a new id), publish the v2 endpoint, migrate clients, then retire v1
+once the last client is off it.
+
+## Don't share an upstream id
+
+The upstream `id` (either set explicitly via `options.id` or inferred from the
+policy name) identifies each user's upstream connection. Two policies sharing
+one id is a configuration error, and **changing** an id on a policy that already
+has stored connections silently disconnects every existing user.
+
+Pick the id once, document it, and treat it as part of the public contract of
+the upstream just like the route path is part of the public contract of the
+gateway.
+
+## Related
+
+- [`McpProxyHandler` reference](./mcp-proxy-handler.mdx) — the full handler
+  contract.
+- [Local development](./local-development.mdx) — run the multi-upstream
+  configuration locally without setting up Auth0.
+- [Connect a gateway to an upstream OAuth provider](../how-to/connect-upstream-oauth.mdx)
+  — every per-upstream option, including manual client registration and
+  shared-OAuth mode.
+- [Curate the tools an upstream exposes](../how-to/curate-tools.mdx) — add a
+  capability filter to one of the routes.
+- [Connect MCP clients](../connect-clients/overview.mdx) — add multiple gateway
+  routes to a single client config.

package/docs/mcp-gateway/code-config/overview.mdx

@@ -0,0 +1,210 @@
+---
+title: "Set up an MCP Gateway"
+sidebar_label: "Set up the gateway"
+description:
+  Wire up the Zuplo MCP Gateway in routes.oas.json and policies.json — pin the
+  compatibility date, register the runtime plugin, configure one OAuth policy
+  and one token-exchange policy per upstream, and add an MCP route.
+---
+
+To turn any Zuplo project into an MCP Gateway, configure five things in source
+control: the compatibility date in `zuplo.jsonc`, the runtime plugin in
+`modules/zuplo.runtime.ts`, one MCP OAuth policy in `config/policies.json`, one
+`mcp-token-exchange-inbound` policy per OAuth-protected upstream, and one route
+per upstream in `config/routes.oas.json`. This guide walks through each piece
+for a single-upstream gateway.
+
+For the conceptual model — what each piece does and why the pieces are split the
+way they are — see [How the MCP Gateway works](../how-it-works.mdx).
+
+## 1. Pin the compatibility date
+
+MCP Gateway features require `compatibilityDate >= 2026-03-01` in `zuplo.jsonc`:
+
+```jsonc title="zuplo.jsonc"
+{
+  "version": 1,
+  "compatibilityDate": "2026-03-01",
+}
+```
+
+New Zuplo projects default to a recent compatibility date, so this only applies
+to existing projects being upgraded to use the MCP Gateway. See
+[Compatibility dates](./compatibility-dates.mdx) for details.
+
+## 2. Register the MCP Gateway plugin
+
+Add a `modules/zuplo.runtime.ts` file that registers `McpGatewayPlugin`:
+
+```ts title="modules/zuplo.runtime.ts"
+import { RuntimeExtensions } from "@zuplo/runtime";
+import { McpGatewayPlugin } from "@zuplo/runtime/mcp-gateway";
+
+export function runtimeInit(runtime: RuntimeExtensions) {
+  runtime.addPlugin(new McpGatewayPlugin());
+}
+```
+
+The plugin registers the OAuth metadata, authorization endpoints, consent page,
+and upstream connect callbacks the gateway needs. It's a no-op when no
+MCP-related policy is present, so adding it to projects that don't yet use the
+gateway has zero runtime cost.
+
+## 3. Define one OAuth policy
+
+The OAuth policy authenticates inbound MCP requests against your identity
+provider. Pick the first-class wrapper for your IdP — the
+[provider catalog](../auth/overview.mdx#identity-providers) lists every
+supported IdP. The Auth0 case looks like this:
+
+```jsonc title="config/policies.json"
+{
+  "name": "auth0-managed-oauth",
+  "policyType": "mcp-auth0-oauth-inbound",
+  "handler": {
+    "module": "$import(@zuplo/runtime/mcp-gateway)",
+    "export": "McpAuth0OAuthInboundPolicy",
+    "options": {
+      "auth0Domain": "$env(AUTH0_DOMAIN)",
+      "clientId": "$env(AUTH0_CLIENT_ID)",
+      "clientSecret": "$env(AUTH0_CLIENT_SECRET)",
+    },
+  },
+}
+```
+
+Each wrapper takes a small set of provider-specific options (a domain, a tenant
+ID, a subdomain, and so on) and derives the OIDC URLs from them. For IdPs
+without a dedicated wrapper — Ory Hydra, Authentik, FusionAuth, PingFederate, a
+custom OIDC server — use the generic `mcp-oauth-inbound` policy. See
+[Configuring a generic OIDC provider](../auth/configuring-generic-oidc.mdx) for
+the worked example.
+
+:::caution
+
+A project can have only one MCP OAuth policy. The gateway rejects any
+configuration with two, regardless of variant. The same policy is attached to
+every MCP route in the project — every route authenticates against the same
+identity provider.
+
+:::
+
+## 4. Define one token-exchange policy per upstream
+
+Each OAuth-protected upstream gets its own `mcp-token-exchange-inbound` policy:
+
+```jsonc title="config/policies.json"
+{
+  "name": "mcp-token-exchange-linear",
+  "policyType": "mcp-token-exchange-inbound",
+  "handler": {
+    "module": "$import(@zuplo/runtime/mcp-gateway)",
+    "export": "McpTokenExchangeInboundPolicy",
+    "options": {
+      "displayName": "Linear",
+      "protectedResourceMetadataUrl": "https://mcp.linear.app/.well-known/oauth-protected-resource",
+      "authMode": "user-oauth",
+      "scopes": [],
+      "clientRegistration": { "mode": "auto" },
+    },
+  },
+}
+```
+
+Name each policy `mcp-token-exchange-<id>`. The id after the prefix identifies
+the upstream in analytics and connect URLs. Changing the id strands any existing
+user-to-upstream connections, so pick it once and keep it.
+
+For per-mode reference and worked examples per provider, see
+[Connect a gateway to an upstream OAuth provider](../how-to/connect-upstream-oauth.mdx).
+
+## 5. Define one route per upstream
+
+Each upstream gets a route in `routes.oas.json`. The handler points at the
+upstream URL; the inbound policy chain attaches the OAuth policy followed by the
+matching token exchange policy:
+
+```jsonc title="config/routes.oas.json"
+{
+  "openapi": "3.1.0",
+  "info": { "title": "MCP Gateway", "version": "0.1.0" },
+  "paths": {
+    "/mcp/linear-v1": {
+      "get,post": {
+        "operationId": "linear-mcp-server",
+        "summary": "Linear MCP Proxy",
+        "x-zuplo-route": {
+          "corsPolicy": "none",
+          "handler": {
+            "module": "$import(@zuplo/runtime/mcp-gateway)",
+            "export": "McpProxyHandler",
+            "options": {
+              "rewritePattern": "https://mcp.linear.app/mcp",
+            },
+          },
+          "policies": {
+            "inbound": ["auth0-managed-oauth", "mcp-token-exchange-linear"],
+          },
+        },
+      },
+    },
+  },
+}
+```
+
+The path is yours to choose — `/mcp/<provider>-v<n>` is the recommended
+convention because it makes the path self-describing and reserves room for
+versioned upgrades, but the gateway works with any path the OpenAPI router
+accepts.
+
+`get,post` is Zuplo's multi-method shorthand. The handler rejects GET with
+`405 Method Not Allowed` because the gateway only speaks stateless Streamable
+HTTP over POST — see [`McpProxyHandler`](./mcp-proxy-handler.mdx) for the full
+handler reference.
+
+Every MCP route must set `operationId`. Across the project, no two MCP routes
+can share an `operationId` or a path, and no two `mcp-token-exchange-*` policies
+can share an upstream `id`. If `operationId` is missing or duplicated, the
+gateway returns a configuration error on the first matching request.
+
+## Verify the gateway is wired up
+
+Start the project with `zuplo dev` and the gateway is reachable at
+`http://127.0.0.1:9000/mcp/linear-v1`. A quick sanity check is to send an
+unauthenticated POST:
+
+```bash
+curl -i -X POST http://127.0.0.1:9000/mcp/linear-v1 \
+  -H "Content-Type: application/json" \
+  -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'
+```
+
+The gateway should return `401 Unauthorized` with a `WWW-Authenticate` header
+that points at the Protected Resource Metadata URL. If you see that, the OAuth
+policy is wired up correctly. See [Local development](./local-development.mdx)
+for the dev-loop specifics, including the loopback-only login shortcut that
+skips your IdP during development.
+
+## Add more upstreams
+
+The pattern is the same for each additional upstream: one MCP OAuth policy stays
+shared across the project, and one `mcp-token-exchange-*` policy and one route
+get added per new upstream MCP server. Per-user state is keyed by
+`(subjectId, upstreamServerId)`, so each user maintains independent connections
+to each upstream they consent to.
+
+For a worked example with two upstreams and the full file layout, see
+[Add multiple upstream MCP servers](./multi-upstream.mdx).
+
+## Related
+
+- [`McpProxyHandler` reference](./mcp-proxy-handler.mdx) — every option and
+  every behavior of the route handler.
+- [Compatibility dates](./compatibility-dates.mdx) — why `2026-03-01` is
+  required and what older dates break.
+- [Local development](./local-development.mdx) — dev-loop, loopback URLs, the
+  `/oauth/dev-login` shortcut, and the `workerd` restart quirk.
+- [Add multiple upstream MCP servers](./multi-upstream.mdx) — one project, many
+  upstream MCP servers.
+- [Curate the tools an upstream exposes](../how-to/curate-tools.mdx) — restrict
+  and re-project the tools, prompts, and resources a route exposes.

package/docs/mcp-gateway/connect-clients/chatgpt.mdx

@@ -0,0 +1,127 @@
+---
+title: "Connect ChatGPT"
+sidebar_label: "ChatGPT"
+description:
+  Connect ChatGPT to a Zuplo MCP Gateway as a custom connector using Developer
+  Mode, complete the OAuth flow, and start using your tools in conversation.
+---
+
+ChatGPT connects to remote MCP servers as **custom connectors**. To add a custom
+connector that exposes general-purpose MCP tools, you need to enable **Developer
+Mode** on your ChatGPT account. Once enabled, paste the gateway URL into
+ChatGPT's connector settings and complete the OAuth flow.
+
+:::note
+
+ChatGPT's general-purpose custom-connector support runs through Developer Mode,
+which is available on Pro, Team, Enterprise, and Edu plans. Before Developer
+Mode shipped, connector support in ChatGPT was limited to read-only Deep
+Research connectors. Use Developer Mode to expose the full range of tools the
+Zuplo MCP Gateway provides.
+
+:::
+
+## Prerequisites
+
+- A Zuplo project with the MCP Gateway plugin configured and at least one MCP
+  route. See the [quickstart](../quickstart.mdx) if you haven't set one up yet.
+- A ChatGPT Pro, Team, Enterprise, or Edu subscription.
+- Developer Mode enabled on your ChatGPT account. The toggle lives in
+  **Settings** → **Connectors** → **Advanced** (the exact location varies by
+  plan; see OpenAI's
+  [Apps SDK documentation](https://developers.openai.com/apps-sdk/) for current
+  instructions).
+
+## Get the route URL
+
+Each MCP route in `config/routes.oas.json` is reachable at
+`https://{deploymentUrl}/{routePath}` once deployed — for example
+`https://{deploymentUrl}/mcp/linear-v1`.
+
+## Add the connector
+
+<Stepper>
+
+1. **Open Connectors settings in ChatGPT.**
+
+   In the ChatGPT web app, open **Settings** → **Connectors**.
+
+2. **Add a custom connector.**
+
+   Click the option to add a custom connector. Depending on your plan, this may
+   be **Add custom connector**, **Create**, or **Advanced** → **Add MCP
+   server**.
+
+3. **Enter the gateway URL.**
+
+   Paste the route URL. Give the connector a name and description — these are
+   what ChatGPT shows in the conversation interface.
+
+4. **Authenticate against the gateway.**
+
+   Save the connector. ChatGPT opens the gateway's OAuth flow. Sign in with the
+   identity provider you configured for the gateway.
+
+5. **Complete the upstream connection.**
+
+   The gateway shows a consent page with the upstream MCP server the route
+   proxies to. Click **Connect** next to the upstream, complete its OAuth flow,
+   then click **Authorize** to finish.
+
+6. **Enable the connector for chats.**
+
+   Back in ChatGPT, enable the connector for the conversations or assistants
+   where you want it active. Tools from the gateway then appear when ChatGPT
+   needs them.
+
+</Stepper>
+
+## What ChatGPT supports
+
+ChatGPT registers itself with the gateway through
+[Dynamic Client Registration (DCR)](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
+and the newer
+[Client ID Metadata Documents (CIMD)](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
+flow. It supports:
+
+- **Tools** — invoke gateway-exposed tools from the conversation.
+- **MCP Apps** — render interactive HTML widgets inline. This is the same
+  surface that powers the OpenAI Apps SDK, which is built directly on top of MCP
+  Apps.
+
+ChatGPT doesn't currently consume prompts, resources, roots, sampling, or
+elicitation from a remote MCP server.
+
+## Build an Apps SDK app on top of the gateway
+
+If you're authoring an MCP server intended to render rich UI inside ChatGPT,
+read OpenAI's [Apps SDK documentation](https://developers.openai.com/apps-sdk/)
+— the Apps SDK builds on the MCP Apps extension, so an Apps SDK app **is** an
+MCP server with UI conventions on top. The Zuplo MCP Gateway forwards
+Apps-related metadata (`_meta.ui.*`) from upstream MCP servers unchanged. Tool
+authors who want to ship UI to ChatGPT should follow the Apps SDK guide; the
+gateway transparently relays the additional metadata to the client.
+
+For more background on Apps SDK and Zuplo-hosted MCP servers, see
+[OpenAI Apps SDK with Zuplo](../../mcp-server/openai-apps-sdk.mdx).
+
+## Troubleshooting
+
+- **"Custom connector" option isn't visible.** Confirm your plan supports
+  Developer Mode (Pro, Team, Enterprise, or Edu) and that Developer Mode is
+  enabled in your settings.
+- **Sign-in succeeds but no tools appear.** Tools only appear when ChatGPT
+  decides to invoke them. Try a prompt that mentions the action you want to
+  take. If the connector itself is disabled in a conversation, ChatGPT doesn't
+  see any of its tools.
+- **OAuth fails with a redirect error.** ChatGPT registers its redirect URI
+  dynamically. The gateway accepts dynamic registration by default. If you've
+  locked down DCR on your identity provider, switch to a provider that supports
+  DCR, or pre-register an OAuth app for ChatGPT.
+
+## Related
+
+- [Connect MCP clients overview](./overview.mdx)
+- OpenAI's [Apps SDK documentation](https://developers.openai.com/apps-sdk/)
+- [OpenAI Apps SDK with Zuplo](../../mcp-server/openai-apps-sdk.mdx)
+- [Authentication overview](../auth/overview.mdx)