Skip to content

feat(probe): wire bridge / host SEP-1865 conformance probe into host-probe#19

Open
chelojimenez wants to merge 1 commit into
mainfrom
feat/wire-bridge-probe
Open

feat(probe): wire bridge / host SEP-1865 conformance probe into host-probe#19
chelojimenez wants to merge 1 commit into
mainfrom
feat/wire-bridge-probe

Conversation

@chelojimenez
Copy link
Copy Markdown
Collaborator

Summary

Wires @modelcontextprotocol/ext-apps/probe (proposed upstream in modelcontextprotocol/ext-apps#675) into the host-probe View and exposes a new server-side assert-bridge-surface tool. Completes the bridge / host conformance surface that assert-window-openai-surface opened for the OpenAI Apps SDK shim.

Builds on the existing host-probe pattern: View captures, uploads via record-host-probe, server tools assert against the snapshot.

What changes

Snapshot (src/host-probe-types.ts)

  • Added bridge?: BridgeProbeSnapshot field on HostProbeSnapshot.

View (src/host-probe.ts)

  • attachBridgeProbe(app) runs before app.connect() — required to observe one-shot lifecycle notifications (tool-input, tool-result, host-context-changed) fired during the initial ui/initialize handshake.
  • Passive capture ({ activeProbes: false }) at startup populates declared hostCapabilities + observed-notification timeline.
  • New "Run bridge active probes" button issues each known View → Host method (ping, tools/*, resources/*, prompts/list, sampling/createMessage, ui/open-link, ui/download-file, ui/message, ui/request-display-mode, ui/update-model-context) with benign payloads and reclassifies based on response. Hosts that gate on consent may show denial dialogs — the probe still treats denials as supported (only -32601 counts as not-supported).
  • New section-bridge panel renders the matrix alongside windowOpenai.

Server (src/index.ts)

  • Widened record-host-probe Zod schema with bridge: z.any().optional().
  • New assert-bridge-surface MCP tool. Inputs:
    • preset: spec-minimal | chatgpt | claude-desktop | copilot | mcpjam-inspector
    • expectedPresentMethods / expectedAbsentMethods (bridge method names)
    • expectedNotifications (Host → View notification methods)
    • expectedHostCapabilities / expectedAbsentHostCapabilities (dot-paths into hostCapabilities)
  • Returns standard { pass, checks[], methods, incoming, hostCapabilities } shape using assertBridgeMethods + assertHostCapabilities from ext-apps/probe.
  • Unknown method names in input lists surface as failed checks (typo guard).

Dependency

Blocked on modelcontextprotocol/ext-apps#675 landing and a release that ships the ./probe package export. Locally verified against file:../ext-apps; reverted to canonical ^1.0.0 in this PR. Bump to the version that introduces ./probe before merging.

Test plan

  • After ext-apps release with ./probe is published, bump dependency in package.json
  • npm run build clean
  • Deploy to learn.mcpjam.com
  • In ChatGPT (apps developer mode) and MCPJam Inspector: call start-host-probe, click "Run bridge active probes" in the View, then call assert-bridge-surface { preset: \"chatgpt\" } (or \"mcpjam-inspector\") and verify the report
  • Repeat in Claude with apps support and M365 Copilot once available; feed observed differences back into ext-apps preset definitions

🤖 Generated with Claude Code

…face

Wires the new `@modelcontextprotocol/ext-apps/probe` module into the
host-probe View and exposes a server-side conformance tool, completing
the bridge / host surface that `assert-window-openai-surface` opened
for the OpenAI Apps SDK shim.

View (`src/host-probe.ts`):
- `attachBridgeProbe(app)` is called BEFORE `app.connect()` so one-shot
  lifecycle notifications (`tool-input`, `tool-result`,
  `host-context-changed`) fired during the initial `ui/initialize`
  handshake are observed without missing the window.
- After connect, `probe.capture({ activeProbes: false })` populates the
  snapshot with declared `hostCapabilities` + the observed-notification
  timeline. Safe at startup (no method probing).
- New "Run bridge active probes" button issues each known View -> Host
  method with a benign payload and reclassifies based on response. Some
  methods may trigger host confirmation dialogs (`ui/open-link`,
  `ui/message`, etc.) — the probe still treats denials as `supported`
  (only `-32601` counts as absent).
- New `section-bridge` panel renders the matrix alongside `windowOpenai`.

Snapshot schema (`src/host-probe-types.ts`):
- Added `bridge?: BridgeProbeSnapshot` field. Width widened in
  `record-host-probe`'s Zod schema so the View can upload it.

Server (`src/index.ts`):
- New `assert-bridge-surface` tool. Inputs: `preset`
  (`spec-minimal | chatgpt | claude-desktop | copilot | mcpjam-inspector`),
  `expectedPresentMethods`, `expectedAbsentMethods`,
  `expectedNotifications`, `expectedHostCapabilities`,
  `expectedAbsentHostCapabilities`. Returns the standard
  `{ pass, checks[], methods, incoming, hostCapabilities }` structure
  using `assertBridgeMethods` + `assertHostCapabilities` from
  `@modelcontextprotocol/ext-apps/probe`.
- Catches unknown method names in the input lists and reports them as
  failed checks (typo guard).

Depends on the bridge-probe module landing in ext-apps and a release
that surfaces the `./probe` package export.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@cloudflare-workers-and-pages
Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Updated (UTC)
❌ Deployment failed
View logs
mcp-app-example 4ed8cdb May 27 2026, 05:10 PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant