From 43d075d71e7fb659b2ca3182f8575536ce6ee78b Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 15:35:20 +0200 Subject: [PATCH 1/2] docs: add MCP Apps research note --- .../2026-09-17-mcp-apps-research-note.md | 26 +++++ ...026-09-17-mcp-apps-research-note-design.md | 24 +++++ research/mcp-apps.md | 95 +++++++++++++++++++ 3 files changed, 145 insertions(+) create mode 100644 docs/superpowers/plans/2026-09-17-mcp-apps-research-note.md create mode 100644 docs/superpowers/specs/2026-09-17-mcp-apps-research-note-design.md create mode 100644 research/mcp-apps.md diff --git a/docs/superpowers/plans/2026-09-17-mcp-apps-research-note.md b/docs/superpowers/plans/2026-09-17-mcp-apps-research-note.md new file mode 100644 index 0000000..bc80a0c --- /dev/null +++ b/docs/superpowers/plans/2026-09-17-mcp-apps-research-note.md @@ -0,0 +1,26 @@ +# MCP Apps Research Note Implementation Plan + +> **For agentic workers:** Execute inline with validation checkpoints. + +**Goal:** Add a sourced MCP Apps research note and assess its Cloud Foundry relevance. + +**Architecture:** Describe MCP Apps as a server-declared UI resource model: tools associate `ui://` HTML resources, hosts render them in sandboxed iframes, and a bridge carries tool data and tool calls between the host and embedded view. + +**Tech Stack:** Markdown, YAML frontmatter, Devbox, Git, GitHub CLI. + +--- + +### Task 1: Write `research/mcp-apps.md` + +- [ ] Add valid frontmatter with MCP Apps sources, tags `[inter-agent-comms, governance, ecosystem-survey]`, and `cf_areas: [capi, uaa, diego]`. +- [ ] Explain the `ui://` resource, tool declaration, host fetch/render flow, sandboxed iframe, and bidirectional communication. +- [ ] Cover SDK roles for view authors, hosts, and MCP server authors, plus the distinction between the official extension and optional host SDKs. +- [ ] Assess security boundaries: iframe sandbox, host capabilities, content security policy, origin/resource trust, tool authorization, and sensitive data. +- [ ] Assess CF relevance for hosted MCP services, gateways, bindings, identity, isolation, and audit. +- [ ] Add questions about host compatibility, tenancy, resource delivery, versioning, policy, and observability. + +### Task 2: Validate and publish + +- [ ] Run `devbox run validate`, `devbox run test`, and `git diff --check`. +- [ ] Stage only the note and approved spec/plan, commit `docs: add MCP Apps research note`, push `research/mcp-apps`, and open a checklist-complete PR targeting `main`. +- [ ] Verify PR metadata and CI with `gh pr view`. diff --git a/docs/superpowers/specs/2026-09-17-mcp-apps-research-note-design.md b/docs/superpowers/specs/2026-09-17-mcp-apps-research-note-design.md new file mode 100644 index 0000000..504d968 --- /dev/null +++ b/docs/superpowers/specs/2026-09-17-mcp-apps-research-note-design.md @@ -0,0 +1,24 @@ +# MCP Apps Research Note Design + +## Goal + +Capture a sourced research note on MCP Apps as the official MCP extension for interactive UIs +served by MCP servers and embedded in compliant AI hosts. + +## Scope + +Cover `ui://` resources, tool metadata, sandboxed iframe rendering, host/UI bidirectional +communication, SDK roles, host capability boundaries, security, and current ecosystem maturity. +Assess CF relevance for hosted MCP services, gateway policy, service bindings, identity, +network isolation, and audit of interactive tool use. + +## Structure and evidence + +Create `research/mcp-apps.md` with the required four sections and frontmatter. Use the MCP Apps +repository, README, specification, API docs, and examples. Clearly distinguish the official +extension/specification from optional host implementations and label CF conclusions as analysis. + +## Validation + +Run Devbox validation and tests, inspect whitespace/staged files, commit the note and plan on +`research/mcp-apps`, push, and open a PR targeting `main` without unrelated artifacts. diff --git a/research/mcp-apps.md b/research/mcp-apps.md new file mode 100644 index 0000000..b91ed6d --- /dev/null +++ b/research/mcp-apps.md @@ -0,0 +1,95 @@ +--- +title: "MCP Apps: Interactive UIs Served by MCP Tools" +author: Ruben Koster (@rkoster) +date: 2026-09-17 +tags: [inter-agent-comms, governance, ecosystem-survey] +cf_areas: [capi, uaa, diego] +status: draft +ratings: + platform-impact: + value: 72 + note: "Interactive tool UIs could make CF-hosted AI services more usable while preserving a governed MCP server boundary." + maturity: + value: 68 + note: "MCP Apps has an official specification and SDK repository with examples, but compliant host support remains an ecosystem concern." + novelty: + value: 76 + note: "The extension standardizes a server-declared UI resource and host bridge instead of returning only text or structured tool data." + actionability: + value: 74 + note: "CF can evaluate MCP Apps at the gateway and hosted-service layers, although host capability and iframe security policies remain client decisions." +sources: + - https://github.com/modelcontextprotocol/ext-apps + - https://raw.githubusercontent.com/modelcontextprotocol/ext-apps/main/README.md + - https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx + - https://apps.extensions.modelcontextprotocol.io/api/ + - https://github.com/modelcontextprotocol/ext-apps/tree/main/examples +--- + +## Summary + +MCP Apps is the official Model Context Protocol extension and SDK for interactive user +interfaces served by MCP servers. A tool declares a `ui://` resource, a compliant host fetches +and renders the resource in a sandboxed iframe, and a bridge allows the view to receive tool +data or request further tool calls through the host. The extension gives Cloud Foundry-hosted +MCP services a way to deliver charts, forms, dashboards, and other interactive views without +moving all UI logic into the AI client. + +## Key findings + +- **The protocol adds UI resources to tools.** An MCP tool can declare a `ui://` resource that + contains its HTML interface. The model calls the tool on the server, then the host fetches + the associated resource and displays it inline in the conversation. +- **Rendering is host-controlled.** MCP Apps views run in a sandboxed iframe rather than being + injected directly into the host application. The host decides whether and how to render the + view, which capabilities to expose, and how to apply its own security and content policies. +- **Communication is bidirectional through a bridge.** The host passes tool results and other + data to the embedded view using notifications, while the view can invoke tools through the + host. This supports interactive forms and dashboards rather than a static HTML attachment. +- **The SDK serves three roles.** Packages support app developers building views, host developers + embedding views, and MCP server authors registering tools and UI metadata. The repository + includes server helpers, an app bridge, React support, and examples. +- **The official extension does not provide every host.** The repository documents the protocol + and SDK but notes that it does not contain a supported full host implementation beyond an + example basic host. Clients may implement their own host or use another compatible framework. +- **Security crosses server, host, and iframe boundaries.** A deployment must control which UI + resources are trusted, constrain iframe capabilities and network access, validate messages, + protect host APIs, and re-check authorization when a view invokes a tool. The UI must not be + treated as a trusted authority merely because it came from an approved MCP server. +- **MCP Apps extends rather than replaces MCP.** Tool discovery, invocation, server identity, + and authorization remain MCP concerns; MCP Apps adds a standardized interactive presentation + associated with a tool. +- **Interactive views introduce lifecycle and compatibility questions.** Resource versions, + host capability negotiation, iframe reloads, tool errors, partial results, and client-specific + rendering differences all need operational handling beyond a simple text response. + +## CF relevance + +Cloud Foundry could host MCP servers that expose MCP Apps views for platform operations, +developer workflows, or business tools. A CF-hosted service could keep backend credentials and +policy on the server while returning a chart, approval form, or dashboard resource to a client +through an MCP gateway. Service bindings could provide endpoint and scoped credentials, while +UAA or another identity service authenticates the user or workload behind tool calls. + +The gateway and hosting boundary remain important. A CF MCP gateway could apply server/tool +policy, record resource and tool access, and prevent unapproved external servers from being +embedded. Diego could run trusted MCP servers, but the host iframe is controlled by the AI +client rather than CF; network isolation, CSP, resource integrity, and sensitive-data handling +must therefore be enforced across both the server and client. Loggregator-compatible events +could correlate a user session, MCP tool call, UI resource, subsequent view action, and backend +operation. + +## Open questions + +- Which MCP Apps hosts and iframe capabilities should CF support or certify for platform-facing + tools? +- How should a CF gateway authorize both the initial tool call and later tool calls initiated + by the embedded view? +- Where should UI resources be stored, versioned, scanned, and served, and how should tenant + isolation apply to cached resources? +- What CSP, network egress, origin, and iframe policies are required for multi-tenant hosted + MCP Apps? +- How should UI resource metadata, tool arguments, user actions, and backend effects be audited + without logging sensitive content? +- Should CF provide reusable MCP Apps views for platform operations, or leave UI catalogs and + host compatibility entirely to application teams? From 4ad750f31b524153e245dc3bde29cc84caadd0a5 Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 15:36:06 +0200 Subject: [PATCH 2/2] chore: refresh generated research map --- generated/research-map.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generated/research-map.html b/generated/research-map.html index bbe5f21..2226967 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,9 +23,9 @@

Focus use cases

Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.
Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.

Core

Supporting

-
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
+
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
 -