@syntrologie/runtime-sdk 2.8.0-canary.126 → 2.8.0-canary.127

package/CAPABILITIES.md

@@ -72,6 +72,7 @@ The SDK includes the following adaptive packages, each providing specific capabi
 - [@syntrologie/adapt-content](#syntrologieadapt-content)
 - [@syntrologie/adapt-faq](#syntrologieadapt-faq)
 - [@syntrologie/adapt-gamification](#syntrologieadapt-gamification)
+- [@syntrologie/adapt-mcp](#syntrologieadapt-mcp)
 - [@syntrologie/adapt-nav](#syntrologieadapt-nav)
 - [@syntrologie/adapt-overlays](#syntrologieadapt-overlays)
 
@@ -830,6 +831,65 @@ Mount gamification UI elements (leaderboard, badge display, progress tracker) vi
 - **Progress tracking**: Show achievement progress to motivate users
 
 
+---
+
+# @syntrologie/adapt-mcp
+
+Loader adaptive for the MCP Apps protocol.
+
+## What it does today
+
+Nothing observable from tile config. This adaptive is currently a pure loader:
+it pulls [`@modelcontextprotocol/ext-apps`](https://www.npmjs.com/package/@modelcontextprotocol/ext-apps) into the page and exposes its `App`, `AppBridge`,
+and `PostMessageTransport` classes on `window.MCPApp`. No actions, no widgets,
+no surfaces.
+
+## Why it exists separately from `runtime-sdk`
+
+The MCP Apps bridge adds a non-trivial amount of code and a new dep
+(`@modelcontextprotocol/ext-apps`) to any page that includes it. Most Syntro
+deployments don't need it — only pages that want to render interactive MCP-app
+cards do. Splitting it into its own adaptive means the runtime stays lean and
+the bridge code only loads when a tile references it.
+
+This package is deliberately **not** listed in `BUNDLED_APP_IDS` in
+`packages/runtime-sdk/src/apps/AppLoader.ts`, so the AppLoader treats it as a
+CDN-hosted adaptive and fetches it on demand.
+
+## Loading
+
+The `./cdn` entrypoint is the CDN bundle. When it runs in a browser:
+
+1. Imports `App`, `AppBridge`, `PostMessageTransport` from
+   `@modelcontextprotocol/ext-apps/app-bridge`.
+2. Assigns them to `window.MCPApp`.
+3. Calls `window.SynOS.appRegistry.register(manifest)` if the host registry is
+   present.
+
+After this runs, any subsequent page code can use `window.MCPApp.App` to
+construct an MCP App instance without reloading the library.
+
+## Capabilities (none yet)
+
+| Kind | Available? | Notes |
+|------|------------|-------|
+| Actions | — | TBD once bridge requirements are defined. |
+| Widgets | — | TBD. |
+| Surfaces | — | TBD. |
+
+This file gets aggregated into `runtime-sdk/CAPABILITIES.md` during build. When
+actions land here, document them in the normal adaptive format (kind, description,
+params schema, example config).
+
+## Next steps (not in this package yet)
+
+- Canvas/host wiring: instantiate `AppBridge` per rendered MCP-app iframe.
+- Action registry: map `data-action` clicks to `app.callTool(...)` invocations.
+- Per-channel MCP client proxy on the canvas server.
+
+Those live in other PRs once we lock in the full interactivity design.
+
+
 ---
 
 # @syntrologie/adapt-nav

package/dist/{chunk-HB2GDS5R.js → chunk-NSFN2DIC.js}

@@ -3640,7 +3640,7 @@ function getAntiFlickerSnippet(config = {}) {
 }
 
 // src/version.ts
-var SDK_VERSION = "2.8.0-canary.126";
+var SDK_VERSION = "2.8.0-canary.127";
 
 // src/types.ts
 var SDK_SCHEMA_VERSION = "2.0";
@@ -12684,4 +12684,4 @@ export {
   encodeToken,
   Syntro
 };
-//# sourceMappingURL=chunk-HB2GDS5R.js.map
+//# sourceMappingURL=chunk-NSFN2DIC.js.map