mirror of https://github.com/CopilotKit/CopilotKit.git synced 2026-09-14 16:26:20 +08:00

Files

T

History

yannj-fr a9933fe12c chore(mcp-apps-renderer): tighten the activity UMD build and attw coverage

Follow-up asks from Ben's review, plus a version alignment:

- Add codeSplitting: false to the activity UMD build (matching a2ui-renderer), so
  it emits a single self-contained activity.umd.js. Without it a sibling chunk
  could leave the CopilotKitMcpAppsRendererActivity global incomplete, and
  es-check (syntax-only) would not catch it.
- Run attw as two analyses instead of a package-wide suppression: the root
  entry with the esm-only profile (it wraps the ESM-only ext-apps bridge, so its
  CJS resolution is intentionally absent while ESM and type checks stay active),
  and the remaining entries with node16. This keeps no-resolution enforced on
  every other entry point instead of silencing the rule for the whole package.
- Bump the package version 1.70.1 to 1.71.0 to match the shared-version monorepo
  scope, and regenerate the public API manifest.

2026-09-10 23:14:08 +02:00

src

docs(mcp-apps-renderer): add docstrings + fix bundle-size package count

2026-09-04 23:01:33 +01:00

package.json

chore(mcp-apps-renderer): tighten the activity UMD build and attw coverage

2026-09-10 23:14:08 +02:00

README.md

fix(mcp-apps-renderer): make the UMD and CJS entry points valid (Codex review)

2026-09-09 17:41:20 +02:00

tsconfig.json

feat(mcp-apps-renderer): scaffold the shared MCP Apps host package

2026-09-03 19:29:15 +01:00

tsdown.config.ts

chore(mcp-apps-renderer): tighten the activity UMD build and attw coverage

2026-09-10 23:14:08 +02:00

vitest.config.mjs

feat(mcp-apps-renderer): scaffold the shared MCP Apps host package

2026-09-03 19:29:15 +01:00

README.md

@copilotkit/mcp-apps-renderer

Framework-agnostic MCP Apps host for CopilotKit: the app↔host protocol on top of @modelcontextprotocol/ext-apps (AppBridge + PostMessage transport, sandbox proxy, per-thread request queue, ui/message / ui/open-link / tools/call proxy, tool input/result forwarding, ui/request-display-mode). The React / Vue / Angular renderers consume it as thin adapters: they create the sandbox iframe and wire reactive state, while all protocol logic lives in bindMcpApp.

Entry points

Import	Contents	Bundle
`@copilotkit/mcp-apps-renderer`	`bindMcpApp` + the full session API	ESM only — it wraps the ESM-only ext-apps bridge, and is meant to be loaded lazily via a dynamic `import()`.
`@copilotkit/mcp-apps-renderer/activity`	`MCPAppsActivityType`, `MCPAppsActivityContentSchema`, `ɵrunMcpFollowUp`	ESM + CJS. Bridge-free: importing it to register the activity does not pull the ext-apps bundle.

The root is ESM-only on purpose: @modelcontextprotocol/ext-apps ships ESM only, so a CommonJS root would emit a require() of an ES module and fail with ERR_REQUIRE_ESM. Consume bindMcpApp via a dynamic import() (which resolves ESM from any module system), and import the bridge-free /activity surface for synchronous activity registration.

Script-tag / UMD usage

This package also ships a UMD build of the bridge-free /activity entry: dist/activity.umd.js, which defines the global CopilotKitMcpAppsRendererActivity.

@copilotkit/react-core's UMD build references that global (it externalizes @copilotkit/mcp-apps-renderer/activity to register the built-in MCP Apps activity). Script-tag consumers of react-core's UMD must therefore load activity.umd.js before @copilotkit/react-core's UMD bundle, alongside the other UMD globals it depends on (React, CopilotKitCore, CopilotKitA2UIRenderer, …):

<!-- ...React, @copilotkit/core, @copilotkit/a2ui-renderer, etc. first... -->
<script src="https://unpkg.com/@copilotkit/mcp-apps-renderer/dist/activity.umd.js"></script>
<script src="https://unpkg.com/@copilotkit/react-core/dist/index.umd.js"></script>

Only the bridge-free /activity surface has a UMD build; the ext-apps bridge itself (bindMcpApp) is loaded lazily via import() and is not part of the UMD graph, so it only loads when an MCP App is actually rendered.