@noodleseed/agent-kit 0.54.0 → 0.56.0

package/skills/codex/examples/customer-auth/README.md

@@ -1,102 +1,174 @@
-# Customer Auth - NoodleSeed.com Firebase customer identity
+# Customer Auth - OIDC identity and customer-routed APIs
 
-This curated example owns the customer/end-user authentication with Firebase bridge capability slot. It is
-the NoodleSeed.com dogfood app for proving that a SaaS app can protect an MCP endpoint with its own customer
-identity provider while still using the generic Noodle Seed authoring API.
+This curated example owns the customer/end-user authentication capability slot. It proves that a SaaS app
+can protect an MCP endpoint with direct OIDC, retain role/scope-based tool authorization, and route ordinary
+reads and confirmed actions to the API origin selected by the verified customer's identity provider.
 
-It also owns the embedded-assistant showcase: the same authenticated MCP surface can be dropped into the
-SaaS web application as a fully customer-branded assistant with independent light and dark themes. The
-assistant loads the active deployment's instructions and model-visible tools rather than installing a stale
-second skill bundle. The standard embedded element also hosts linked MCP Apps behind its sandbox bridge.
+It also owns the customer-branded embedded-assistant presentation showcase. Embedded sessions lack
+direct/federated MCP OIDC endpoint claims, so these routed tools fail with `connector_route_unavailable`;
+static connectors still support embedded delegated exchange. Exercise routed tools through the MCP endpoint.
 
-The public developer entrypoint is [`src/server.ts`](src/server.ts). It declares `customerAuth.firebase(...)` with
-the NoodleSeed.com Firebase project and Firebase Web App public config. It exposes a deliberately small MCP
-surface for org discovery:
+The public developer entrypoint is [`src/server.ts`](src/server.ts). It exposes a deliberately small MCP
+surface for organization discovery and app lifecycle operations:
 
 - `list_my_organizations` lists the NoodleSeed.com organizations the signed-in customer belongs to (no
   arguments — the org set comes from the verified customer session).
-- `list_org_apps` lists apps for one of those organizations through the dev app API. It is visible and
+- `list_org_apps` lists apps for one of those organizations through that tenant's API. It is visible and
   callable only when the verified customer has the `org_apps:read` scope and either the `org_admin` or
   `org_member` role.
+- `archive_org_app` archives one app only after exact runtime confirmation. It requires the
+  `org_apps:write` scope and `org_admin` role.
 
-The two tools chain: `list_my_organizations` surfaces the `org_id`s the customer can act on, and
-`list_org_apps` takes one of those `org_id`s. There is no NoodleSeed-specific SDK helper. The downstream API
-is an ordinary authored HTTP connector.
+The tools chain: `list_my_organizations` surfaces the `org_id`s the customer can act on,
+`list_org_apps` takes one of those ids, and `archive_org_app` accepts the selected app id. Tool code remains
+independent of the selected origin.
 
-## Direct or federated OIDC instead of the built-in adapter
+## Declare the customer endpoint
 
-This flagship uses the managed Firebase adapter. If an app replaces it with `customerAuth.oidc(...)` or
-`customerAuth.federatedOidc(...)`, the app developer owns the authorization server. It must publish the
-primary path-inserted RFC 8414 URL as direct HTTP 200 JSON with the exact issuer, HTTPS authorization/token/
-registration/JWKS endpoints, authorization-code and refresh grants, PKCE S256, public-client auth method
-`none`, RFC 8707 resource handling, an access-token `aud` equal to the exact MCP URL, and public signing keys.
+`customerEndpoint` names one private routing authority and bounds the origins an IdP may select:
 
-Run `noodle auth doctor src/server.ts` before sharing the endpoint. Its issuer-readiness probes perform
-bounded read-only GET checks and never register a client. A successful
-`noodle deploy --access customers` reports the same findings as nonblocking warnings; the application team
-repairs the issuer rather than adding a Noodle OAuth proxy.
-
-Adding the embedded assistant does not choose or rewrite MCP customer auth. Inspect the exact active
-deployment before changing configuration:
-
-```sh
-noodle deployments list --org <org> --app <app> --env <env> --json
+```ts
+const customerApi = customerEndpoint('customer_api', {
+  allowedHttpsHostSuffixes: ['api.noodleseed.dev'],
+});
 ```
 
-This Firebase bridge intentionally advertises the Noodle authorization server. A direct or federated
-replacement must advertise its configured tenant issuer. If the exact active direct/federated `customers`
-deployment instead advertises the platform issuer, report `customer_auth_state_inconsistent` with only the
-endpoint, deployment ID, server version, and sanitized protected-resource metadata. Do not share tokens or
-secrets, proxy or rewrite metadata, rotate credentials, or redeploy repeatedly to conceal the mismatch.
+Use either non-empty `allowedHttpsHostSuffixes` or non-empty `allowedHttpsOrigins`, never both. Exact-origin
+policies may include a non-default port. Suffix policies match only the exact hostname or dot-boundary
+subdomains on port 443. A routed connector must not add `allowedOrigins`; its endpoint policy is the egress
+allowlist.
 
-During MCP OAuth login, Noodle Cloud hosts the Firebase bridge page at
-`https://cloud.noodleseed.dev/oauth/customer/firebase/authorize`. The customer app does not add an
-authorization route. The SaaS operator only configures Firebase Auth to allow the Noodle Cloud origin, and
-Noodle Cloud signs the customer in with Firebase before posting the Firebase ID token back to its own bridge
-callback.
+The connector uses that declaration as its normal base URL. Its token endpoint remains a fixed, independently
+validated HTTPS URL:
 
-## How delegated customer credentials are used
+```ts
+const api = connector('noodleseed_app_api')
+  .version('1.0.0')
+  .http({
+    baseUrl: customerApi,
+    auth: {
+      kind: 'delegatedTokenExchange',
+      tokenUrl: 'https://id.noodleseed.dev/oauth/token',
+      clientId: variable('CUSTOMER_API_CLIENT_ID'),
+      clientSecret: secret('CUSTOMER_API_CLIENT_SECRET'),
+      scopes: ['organizations:read', 'org_apps:read', 'org_apps:write'],
+      audience: 'noodleseed-customer-api',
+    },
+    operations: {
+      // read and action operations...
+    },
+  });
+```
 
-This flagship uses the legacy Firebase provider bridge because it is runnable today. That is distinct from
-Core-v2 account-selecting connector aliases: those declare catalog `credentialProfiles` and bind each alias
-with `bind(connector, { profile, connection })`. Hosted bound `managedSecret(...)` connections are runnable;
-bound `externalExchange()` and `clientCredentials(...)` currently compile as portable metadata but fail
-closed before secret or network access until their provider slice lands. Do not replace this example's
-working delegated-session-cookie path with either unsupported bound exchange source.
+## Map the endpoint from verified OIDC
 
-The example has two declarations that work together:
+The IdP claim contains the complete base URL, including an optional base path. Routing is separate from the
+public `${user}` expression scope:
 
 ```ts
-auth: customerAuth.firebase({
-  projectId: variable('FIREBASE_PROJECT_ID'),
-  apiKey: variable('FIREBASE_WEB_API_KEY'),
-  authDomain: variable('FIREBASE_AUTH_DOMAIN'),
-  user: {
+auth: customerAuth.oidc({
+  issuer: 'https://id.noodleseed.dev',
+  audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+  claims: {
     id: 'sub',
     email: 'email',
     name: 'name',
-    tenant: 'firebase.tenant',
-        orgs: 'claims.orgs',
-        roles: 'claims.roles',
-        scopes: 'claims.scopes',
+    orgs: 'permissions.orgs',
+    roles: 'permissions.roles',
+    scopes: 'permissions.scopes',
+  },
+  routing: {
+    endpoints: {
+      customer_api: { claim: 'tenant.api_base_url' },
+    },
+  },
+}),
+```
+
+For federated OIDC, put the same endpoint map on every issuer. Claim paths may differ, but each issuer must
+map every endpoint the app uses:
+
+```ts
+auth: customerAuth.federatedOidc({
+  issuers: [
+    {
+      issuer: 'https://id.customer-a.com',
+      audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+      routing: {
+        endpoints: {
+          customer_api: { claim: 'tenant.api_base_url' },
+        },
       },
+    },
+    {
+      issuer: 'https://login.customer-b.com',
+      audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+      routing: {
+        endpoints: {
+          customer_api: { claim: 'organization.routes.customer_api' },
+        },
+      },
+    },
+  ],
 }),
 ```
 
-That protects the MCP endpoint with the SaaS customer's Firebase identity. The connector then opts into
-delegated customer credentials:
+At runtime, Noodle Seed validates both the configured audience and exact MCP resource, projects the route
+into private request state, applies its policy, and freezes it for the call. Missing, malformed, or
+disallowed claims return `connector_route_unavailable` before credential lookup or connector egress.
+Resolved URLs never enter artifacts, `${user}`, logs, model output, widgets, public confirmation review,
+broker cache keys, or delegated exchange assertions.
+
+Routed reads work in tools, including declared nested calls. Routed actions require exact
+`annotations.confirm: true`; otherwise they fail with `customer_endpoint_action_unsupported`. Routed
+resources, prompts, and ambient context fail with `customer_endpoint_surface_unsupported`.
+
+The flagship's routed action uses the normal TypeScript action helper:
 
 ```ts
-auth: {
-  kind: 'delegatedSessionCookie',
-  provider: 'firebase',
-  sessionUrl: `${noodleseedApiOrigin}/api/auth/session`,
-  tokenField: 'idToken',
+tool('archive_org_app', {
+  authorization: {
+    requiredScopes: ['org_apps:write'],
+    allowedRoles: ['org_admin'],
+  },
+  annotations: annotations.openAction({ destructive: false, confirm: true }),
+  // input, output, and the normal connectors.app_api.archiveOrgApp(...) call...
+});
+```
+
+The flagship also opts into the current stateless hosted MCP path:
+
+```ts
+interactions: {
+  confirmationFallback: 'host',
 },
 ```
 
-The mapped `roles` and `scopes` paths are read only after Firebase verifies the ID token. The restricted
-tool declares its rule beside the rest of its public contract:
+A bidirectional client that negotiated form elicitation can complete the standard confirmation exchange
+instead. The explicit host fallback trusts the MCP host to have collected native write approval before the
+tool call reaches Noodle Seed; it is never inferred from client identity and does not replace auth, policy,
+or accurate action/destructive annotations. Omit the fallback when connected hosts are not trusted to
+provide that approval. If neither standard confirmation nor the fallback is available, the action fails
+closed with `interaction_unavailable`.
+
+Preparation stores only sorted route `{ key, fingerprint }` bindings in its private server-held
+continuation; the public review exposes none of them. Acceptance re-resolves the current request route and
+returns `invalid_continuation` if it is missing or changed, before policy, credentials, or egress. A match
+reuses the current frozen snapshot for the action and all nested or later reads.
+
+The application developer owns the direct/federated authorization server. It must publish its path-inserted
+RFC 8414 document as direct HTTP 200 JSON with exact issuer and HTTPS authorization/token/registration/JWKS
+endpoints, authorization-code and refresh grants, PKCE S256, public-client auth method `none`, RFC 8707
+resource handling, and public signing keys. Access tokens must include the exact MCP resource audience; there
+is no audience fallback.
+
+Run `noodle auth doctor src/server.ts` before sharing. Its bounded, read-only probes never register a client.
+Adding the embedded assistant does not choose or rewrite MCP customer auth.
+
+## Per-tool authorization remains independent
+
+The mapped `roles` and `scopes` paths are read only after OIDC verification. The restricted tool declares its
+rule beside the rest of its public contract:
 
 ```ts
 tool('list_org_apps', {
@@ -109,9 +181,9 @@ tool('list_org_apps', {
 ```
 
 Every required scope must be present and at least one allowed role must match. When both lists are declared,
-both conditions apply. A restricted tool is omitted from `tools/list` for an ineligible customer and a
-direct `tools/call` still fails closed. Do not use unverified page context, request arguments, connector
-responses, or an arbitrary generic `roles` claim as authorization input.
+both conditions apply. Route availability never changes `tools/list`: discovery remains based only on
+roles/scopes. A restricted tool is omitted for an ineligible customer and a guessed direct call still fails
+closed.
 
 Tool code calls the connector normally:
 
@@ -127,39 +199,13 @@ fulfil({ input, connectors }) {
 }
 ```
 
-At runtime, Noodle Seed verifies the Firebase customer during MCP OAuth, stores that customer's delegated
-Firebase refresh token in the credential broker, and refreshes a short-lived Firebase ID token only when a
-connector-backed tool calls the NoodleSeed.com API. For this app API, the broker exchanges that ID token at
-the existing Next.js `/api/auth/session` route and sends the resulting session cookie to the API. The MCP
-access token remains a Noodle-issued resource-bound token and is never sent to the downstream API.
-
-## Delegated downstream auth for your own API (token exchange)
-
-The Firebase path above only works for Firebase-session downstreams. When the downstream is **your own
-API** with its own token issuance, use `delegatedTokenExchange` instead
-([ADR 0152](../../docs/decisions/0152-delegated-token-exchange-connector-auth.md)): the platform signs a
-short-lived, JWKS-verifiable assertion of the signed-in user and exchanges it (RFC 8693) at a token
-endpoint you implement, which mints your own user-scoped token — so your API enforces its own per-user
-authorization on every call. It works for verified direct/federated OIDC, built-in provider identities, and
-embedded assistant sessions, with no per-user OAuth enrollment.
-
-```ts
-auth: {
-  kind: 'delegatedTokenExchange',
-  tokenUrl: 'https://app.example.com/api/assistant/oauth/token', // origin must be in allowedOrigins
-  clientId: variable('EXAMPLE_DELEG_CLIENT_ID'),
-  clientSecret: secret('EXAMPLE_DELEG_CLIENT_SECRET'),
-  scopes: ['time_off'],
-},
-```
+The broker exchanges a short-lived, platform-signed assertion at the fixed token endpoint and caches the
+result by caller, connector, scopes, and a route fingerprint. The assertion carries only the route key and
+fingerprint, never the URL. The MCP access token is never forwarded to the customer API. The exchange wire
+contract lives in [docs/spec/connectors.md](../../docs/spec/connectors.md).
 
-Your endpoint authenticates the broker's client credential, verifies the `subject_token` JWT against the
-platform issuer JWKS (claims include the verified `sub`, `email`, `name`, declared session `claims`,
-`tenant`, and `deployment`), mints a short-lived user-scoped token, and returns the standard
-`{ access_token, token_type, expires_in }` response. The exact wire contract and a copyable endpoint
-implementation live in [docs/spec/connectors.md](../../docs/spec/connectors.md) and the Agent Kit
-authoring-workflow reference ("Delegated downstream auth"). `noodle auth doctor` reports each declared
-exchange endpoint.
+Firebase and Microsoft remain supported managed adapters; their provider-specific contracts and tests live
+in [docs/spec/auth-and-policy.md](../../docs/spec/auth-and-policy.md) and the SharePoint flagship.
 
 ## Validate
 
@@ -170,7 +216,7 @@ noodle validate examples/customer-auth/src/server.ts
 
 Against a deployed customer-protected environment, set a short-lived real customer token only in
 `NOODLE_CUSTOMER_TOKEN` and add `--live --org <org> --app <app> --env <env>`. The live doctor performs
-credential exchanges without invoking either business tool.
+credential exchanges without invoking any business tool.
 
 ## Run locally
 
@@ -184,13 +230,16 @@ The embedded assistant uses a customer-supplied OpenAI Chat Completions-compatib
 managed values at the Noodle deployment environment; none of these values belongs in the customer web
 application environment, and the API key never reaches the browser:
 
+The assistant session carries a verified user, tenant, deployment, roles, and scopes, but not the IdP's
+`tenant.api_base_url` claim. These routed operations are MCP-only; do not copy the route into page context,
+session claims, tool input, or model instructions.
+
 ```bash
 noodle variables set ASSISTANT_MODEL_BASE_URL https://model.example.com/v1 --scope env
 noodle variables set ASSISTANT_MODEL your-model --scope env
 noodle secrets set ASSISTANT_MODEL_API_KEY --scope env
-noodle variables set FIREBASE_PROJECT_ID your-firebase-project --scope env
-noodle variables set FIREBASE_WEB_API_KEY your-firebase-web-api-key --scope env
-noodle variables set FIREBASE_AUTH_DOMAIN your-firebase-project.firebaseapp.com --scope env
+noodle variables set CUSTOMER_API_CLIENT_ID your-broker-client-id --scope env
+noodle secrets set CUSTOMER_API_CLIENT_SECRET --scope env
 noodle check --target embedded-assistant src/server.ts
 ```
 
@@ -198,11 +247,9 @@ Assistant origins are exact. Production embedding origins must use HTTPS; plain
 loopback development origins such as `http://localhost:3000`, `http://127.0.0.1:3000`, or
 `http://[::1]:3000`. `noodle dev` serves the MCP project, not that separate embedding application.
 
-The assistant's panel, launcher, status header, composer, and message treatment are configured through the
-bounded `presentation` object in `src/server.ts`. The Atlas-style product treatment is the supported
-customization ceiling. These primitives derive their colors from the shared server `branding` block and
-require no edits to `@noodleseed/assistant`; raw HTML, CSS, inline SVG, renderer class names, and callbacks
-are intentionally not accepted in deployment configuration.
+The bounded `presentation` object configures the panel, launcher, header, composer, and messages. Its
+primitives derive colors from shared server `branding`; raw HTML, CSS, inline SVG, renderer classes, and
+callbacks are not accepted.
 
 Create the backend credential after deployment. The CLI writes it to a mode-0600 file and never prints the
 secret:
@@ -382,13 +429,15 @@ secret allowlist; regenerate existing framework-owned environment binding types
 Devtools/model exercises to synthetic data, and obtain approval before sending real connector data to an
 external model.
 
-After deployment, verify the public delegated exchange without extracting a customer bearer token or invoking
-a business operation:
+After deployment, use the assistant doctor to verify the embed client, model, and static session boundary:
 
 ```sh
 noodle assistant doctor --user-id <real-test-user> --origin "$PUBLIC_APP_ORIGIN" --org <org> --app <app> --env <env>
 ```
 
+This does not add an OIDC customer route. Routed operations succeed only through a direct/federated
+customer-authenticated MCP request with an allowed endpoint claim.
+
 If the application deliberately sends a first turn on mount, do not combine a persistent "sent" ref with a
 mount effect. React Strict Mode can abort that provisional request and then suppress the stable remount.
 Schedule the send after the provisional cleanup and settle its promise:
@@ -437,43 +486,21 @@ assistant.subscribeChat((state) => {
 });
 ```
 
-`theme="auto"` follows the browser operating-system preference, not a SaaS-owned theme toggle. Pass the
-application's resolved `light`/`dark` theme to both `NoodleAssistant` and `NoodleAppView`; later updates
-reach mounted MCP Apps without remounting them. CSS custom properties inherit through the assistant host, so
-typed appearance roles may reuse existing application tokens with `var(--app-token)`. The server-level
-`branding` block is inherited by both MCP App widgets and the assistant; documented `--ns-assistant-*`
-semantic CSS variables remain the final integration escape hatch. There is no second assistant branding
-declaration.
-The end-user UI contains only customer branding.
-Text streams progressively. Expired turns re-exchange through the authenticated backend and retry once;
-consent-bound tool confirmations never replay automatically.
-
-The Firebase project ID is required because Firebase ID tokens use the project ID as the token audience and
-issuer suffix. The runtime verifies `aud` against the project ID and `iss` against
-`https://securetoken.google.com/<projectId>`.
-
-The Firebase Web API key and auth domain are public Firebase browser configuration. They let the Noodle
-Cloud-hosted bridge initialize Firebase Auth for this customer project; they are not server secrets. Keep
-them out of source with `variable(...)`, restrict the Firebase key to the expected browser origins and APIs,
-and use `secret(...)` only for credentials that must never reach a browser.
-
-The `noodleseed_app_api` connector currently points at the NoodleSeed.com dev app surface:
-
-```text
-https://dev.noodleseed.com
-```
-
-When the customer app moves from `dev.noodleseed.com` to `app.noodleseed.com`, update the connector's
-`noodleseedApiOrigin` constant to the production API origin that serves the same paths.
+`theme="auto"` follows the operating-system preference, not a SaaS-owned toggle. Pass the resolved
+`light`/`dark` theme to `NoodleAssistant` and `NoodleAppView`; updates reach mounted MCP Apps without a
+remount. CSS custom properties inherit through the host, and documented `--ns-assistant-*` variables remain
+the final integration escape hatch. Server `branding` is shared by widgets and the assistant; there is no
+second branding declaration. Text streams progressively. Expired turns re-exchange and retry once;
+confirmations never replay automatically.
 
-The connector uses delegated Firebase customer credentials. During the customer OAuth bridge, Noodle Seed
-verifies the Firebase ID token, stores the Firebase refresh token through the credential broker, and refreshes
-a Firebase ID token when the connector calls the NoodleSeed.com app API. The broker then exchanges that ID
-token for the app's existing Next.js session cookie. There is no shared `NOODLESEED_APP_API_TOKEN` for this
-example.
+The customer IdP must place the full tenant API base URL in `tenant.api_base_url`. For example, one verified
+customer may receive `https://customer-a.api.noodleseed.dev/v1` and another
+`https://customer-b.api.noodleseed.dev/v1`; both satisfy the declared suffix policy. Application code,
+deployment variables, and connector arguments do not select the tenant route.
 
-Firebase Auth must list `cloud.noodleseed.dev` as an authorized domain before browser sign-in works in
-production.
+`CUSTOMER_API_CLIENT_ID` and `CUSTOMER_API_CLIENT_SECRET` authenticate only the broker to the fixed exchange
+endpoint. They are not customer API bearer tokens. The exchange endpoint verifies the platform-signed
+subject assertion and mints a short-lived token scoped to the signed-in user and route binding.
 
 ## Deploy customer-protected to Noodle Seed Cloud
 
@@ -496,14 +523,16 @@ https://cloud.noodleseed.dev/o/noodleseed/customer-auth/mcp
 - Tool `list_my_organizations`: calls `GET /api/organizations` and returns the organizations the signed-in
   customer is a member of. Takes no arguments; the org set is scoped by the verified customer session.
 - Tool `list_org_apps`: calls `GET /api/organizations/{org_id}/apps` for one organization `org_id`.
+- Tool `archive_org_app`: after confirmation, calls
+  `POST /api/organizations/{org_id}/apps/{app_id}/archive`.
 
 ## Auth boundary
 
-Firebase ID-token verification is handled by Noodle Seed's generic Firebase bridge adapter during OAuth
-issuance. The MCP client receives a Noodle-issued, resource-bound access token marked as a Firebase customer
-identity; raw Firebase tokens and inbound MCP bearer tokens are never forwarded to tools, connectors,
-widgets, or downstream systems.
+Noodle Seed verifies the configured OIDC issuer, audience, and exact MCP resource before reading identity or
+routing claims. Public caller identity contains the user/role/scope projection; the customer route remains
+private request state.
 
-The connector-backed tools use the credential broker to turn the signed-in Firebase customer session into the
-same session-cookie credential that the existing NoodleSeed.com Next.js API already expects. The inbound MCP
-bearer token is never used as an app API credential.
+Connector-backed tools ask the broker for a route-bound delegated credential; only the endpoint key and
+fingerprint enter broker cache/single-flight state or the assertion. The route claim and inbound MCP bearer
+token never reach tools, connectors, widgets, model output, or downstream systems. Confirmed actions keep
+the same URL-blind binding only in private continuation state and reject acceptance-time drift.

package/skills/codex/examples/customer-auth/src/server.ts

@@ -2,6 +2,7 @@ import {
   annotations,
   connector,
   customerAuth,
+  customerEndpoint,
   embeddedAssistant,
   openAICompatible,
   secret,
@@ -11,18 +12,21 @@ import {
   z,
 } from '@noodleseed/one';
 
-const noodleseedApiOrigin = 'https://dev.noodleseed.com';
+const customerApi = customerEndpoint('customer_api', {
+  allowedHttpsHostSuffixes: ['api.noodleseed.dev'],
+});
 
 const noodleseedApi = connector('noodleseed_app_api')
   .version('1.0.0')
   .http({
-    baseUrl: noodleseedApiOrigin,
-    allowedOrigins: [noodleseedApiOrigin],
+    baseUrl: customerApi,
     auth: {
-      kind: 'delegatedSessionCookie',
-      provider: 'firebase',
-      sessionUrl: `${noodleseedApiOrigin}/api/auth/session`,
-      tokenField: 'idToken',
+      kind: 'delegatedTokenExchange',
+      tokenUrl: 'https://id.noodleseed.dev/oauth/token',
+      clientId: variable('CUSTOMER_API_CLIENT_ID'),
+      clientSecret: secret('CUSTOMER_API_CLIENT_SECRET'),
+      scopes: ['organizations:read', 'org_apps:read', 'org_apps:write'],
+      audience: 'noodleseed-customer-api',
     },
     operations: {
       list_org_apps: {
@@ -49,6 +53,19 @@ const noodleseedApi = connector('noodleseed_app_api')
           organizations: '${response.organizations}',
         },
       },
+      archive_org_app: {
+        type: 'action',
+        method: 'POST',
+        path: '/api/organizations/${args.org_id}/apps/${args.app_id}/archive',
+        input: z.object({
+          org_id: z.string(),
+          app_id: z.string(),
+        }),
+        output: z.object({ archived: z.boolean() }),
+        response: {
+          archived: '${response.archived}',
+        },
+      },
     },
   });
 
@@ -69,22 +86,26 @@ export default server(
       },
     },
     use: { app_api: noodleseedApi },
-    auth: customerAuth.firebase({
-      projectId: variable('FIREBASE_PROJECT_ID'),
-      apiKey: variable('FIREBASE_WEB_API_KEY'),
-      authDomain: variable('FIREBASE_AUTH_DOMAIN'),
-      user: {
+    interactions: { confirmationFallback: 'host' },
+    auth: customerAuth.oidc({
+      issuer: 'https://id.noodleseed.dev',
+      audience: 'https://org.cloud.noodleseed.dev/app/mcp',
+      claims: {
         id: 'sub',
         email: 'email',
         name: 'name',
-        tenant: 'firebase.tenant',
-        orgs: 'claims.orgs',
-        roles: 'claims.roles',
-        scopes: 'claims.scopes',
+        orgs: 'permissions.orgs',
+        roles: 'permissions.roles',
+        scopes: 'permissions.scopes',
+      },
+      routing: {
+        endpoints: {
+          customer_api: { claim: 'tenant.api_base_url' },
+        },
       },
     }),
     instructions:
-      'Customer-authenticated demo. Firebase proves the customer identity, while read-only NoodleSeed.com API calls use broker-managed delegated Firebase customer credentials.',
+      'Direct/federated MCP OIDC demo. The customer IdP proves identity and privately selects the tenant API base URL, while the broker supplies delegated credentials and confirmed actions stay bound to the reviewed route.',
     assistant: embeddedAssistant({
       model: openAICompatible({
         baseUrl: variable('ASSISTANT_MODEL_BASE_URL'),
@@ -111,13 +132,13 @@ export default server(
         },
         composer: { leadingIcon: 'brand-mark', shape: 'pill' },
       },
-      suggestedPrompts: ['Show my organizations', 'List the apps in my organization'],
+      suggestedPrompts: ['Explain how to connect this customer-authenticated MCP server'],
     }),
   },
   [
     tool('list_org_apps', {
       title: 'List organization apps',
-      description: 'List NoodleSeed.com apps for an organization from the dev app API.',
+      description: 'List NoodleSeed.com apps for an organization from its customer API.',
       authorization: {
         requiredScopes: ['org_apps:read'],
         allowedRoles: ['org_admin', 'org_member'],
@@ -147,7 +168,7 @@ export default server(
       description: 'List the NoodleSeed.com organizations the signed-in customer belongs to.',
       contextProvider: true,
       input: z.object({}),
-      // The dev app API returns every organization for the signed-in customer in one response, with no
+      // The customer API returns every organization for the signed-in customer in one response, with no
       // page parameter to pass through, so the bound is declared on the shape. A customer belongs to a
       // handful of organizations; `noodle check` reports an unbounded list as
       // `tool_design_output_bounds`.
@@ -162,5 +183,30 @@ export default server(
         };
       },
     }),
+    tool('archive_org_app', {
+      title: 'Archive organization app',
+      description: 'Archive one NoodleSeed.com app through its customer API after confirmation.',
+      authorization: {
+        requiredScopes: ['org_apps:write'],
+        allowedRoles: ['org_admin'],
+      },
+      input: z.object({
+        org_id: z.string().meta({ title: 'Organization' }),
+        app_id: z.string().meta({ title: 'App' }),
+      }),
+      output: z.object({
+        archived: z.boolean(),
+      }),
+      annotations: annotations.openAction({ destructive: false, confirm: true }),
+      fulfil({ input, connectors }) {
+        const result = connectors.app_api.archiveOrgApp({
+          org_id: input.org_id,
+          app_id: input.app_id,
+        });
+        return {
+          archived: result.archived,
+        };
+      },
+    }),
   ],
 );