Overview of 973: The Web’s Next Form — MCP UI (with Kent C. Dodds)
This episode explores MCP (Model Context Protocol) and MCP UI (the effort to return interactive UI/widgets from model tool-calls) with educator and developer Kent C. Dodds. Kent explains what MCP is, how it’s being used to let models call reusable tools and surface rich interactive UI inside chat/agent hosts, current implementations (ChatGPT Apps / MCP Apps), developer workflows and tooling, practical examples, limitations and security trade-offs, and where the ecosystem is heading.
Key topics covered
- What MCP (Model Context Protocol) is and why it matters
- Tool-calling and context engineering for LLMs
- MCP UI / MCP Apps — returning HTML/CSS/JS as interactive widgets inside chat/agent hosts
- Differences and overlap between MCP, Skills, ChatGPT Apps, and other approaches
- Developer workflow, debugging, testing, and DX pain points
- Real-world examples (Sentry, Media RSS, pizza bot demo, calculator/Tron demo)
- Hosts and adopters (ChatGPT, Cursor, VS Code, Postman, Goose by Block)
- Security, CSP, and why returned UI must be served as static assets today
- The spec evolution (Linux Foundation donation, multi-vendor participation)
What MCP is (simple explanation)
- MCP = Model Context Protocol. It standardizes how LLM agents discover and call external tools, share metadata, and exchange structured data with those tools.
- Goal: remove the fragile copy-paste pattern (copying context into/out of the chat) and let models call tools/services directly in a predictable, reusable, interoperable way.
- Useful when you want: reusable, controlled tool access across agents/hosts; more predictable behavior than giving raw OpenAPI/Swagger to a model.
Why MCP matters (main benefits)
- Normalizes tool interfaces across different agents/hosts (like “jQuery of context management”).
- Lets third-party services (Sentry, etc.) expose useful context/tools to any MCP-enabled agent.
- Enables agents on phones and in desktop apps to leverage your services without embedding APIs everywhere.
- Paves the way for richer interactions than plain text: interactive widgets, carousels, images, buttons.
MCP UI / MCP Apps — returning interactive UI
- MCP UI (and the emerging “MCP Apps” extension) lets an MCP server return HTML/CSS/JS resources (widgets) that a host can render inside a conversation or side panel.
- The host renders a static resource (HTML + JS bundles) and the UI can interact with the conversation by calling MCP tool endpoints (click button → tool call → model/chat updates).
- For security, returned UI must be served as static resources (host must validate CSP and allowed domains). The spec includes metadata for CSP and resource whitelisting.
- Hosts that support MCP Apps or MCP UI: ChatGPT Apps (adapter exists), Postman, Cursor, experimental VS Code support, Goose, and others.
How it works technically (developer view)
- Tool registration: define tools with schemas (arguments, return shapes), titles, descriptions. These become available to agents.
- Distribution:
- Local: run as a local process and communicate over stdio (good for editor integration; publishable as npm/NPX).
- Remote: HTTP streaming interface (host connects to your remote MCP server; send events; post tool calls).
- UI flow: MCP server returns metadata + static resource URLs. Hosts fetch and render the widget. The widget can make tool calls back to the MCP server and/or signal the conversation to continue.
- Dynamic discovery: modern implementations are moving to dynamically include only relevant tools (post-prompt filtering) to avoid context bloat in the model.
Developer DX, testing and tooling
- Feedback loops are currently slower than typical modern front-end dev (lack of HMR, slow connector refresh in some hosts).
- Debugging tools:
- Inspector / MCP Jam: local tooling to add MCP servers, inspect tools/resources/templates, fire individual tool calls and view responses.
- Testing:
- Server code often does not require LLM evals, but tool descriptions/titles/metadata do affect model behavior — these should be evaluated (evals) to ensure reliability.
- Testing workflows are early and evolving; more robust patterns will develop with adoption.
- Common pain points: context blow (too many tool descriptions in the prompt), regenerating connectors, slow end-to-end test loops.
Security & limitations (current restrictions)
- Returned UI must be static and served via a resource URL; hosts restrict dynamic arbitrary HTML/JS run to protect users.
- Hosts provide CSP suggestions and enforce allowed domains/resources.
- Automatic programmatic generation of arbitrary markup by the model (having the model dynamically return fresh HTML/JS) is mostly restricted for security; workarounds (sampling, borrowing LLM for generation) exist but aren’t part of the core spec yet.
- Models require tool metadata up front, which contributes to context usage — mitigations include dynamic tool discovery and sending only relevant tool metadata after the user prompt.
Differences: MCP vs Skills vs ChatGPT Apps
- Skills/Recipes: lighter-weight, shareable scripts or decision flows describing how to accomplish tasks (good for copy/paste team workflows).
- MCP: broader protocol for tool/tool discovery, reuse across agents, host/server interoperability, and richer tool interactions; better when you want reuse across many agents/hosts or tighter control over calls.
- ChatGPT Apps: a big consumer-facing implementation; ChatGPT adopted similar ideas and created an Apps SDK. MCP Apps is being developed as an open extension, with participation from OpenAI, Anthropic, Microsoft, Google, and others.
Practical examples mentioned
- Sentry: example of a service exposing an MCP server to give chat access to bug context.
- Media RSS (Kent’s app): MCP server used to manage personal audio-book RSS feeds; Kent asks ChatGPT to suggest and add books.
- Currency conversion & math servers: simple MCP servers that give models access to live rates/calculators.
- Pizza ordering demo: an MCP server used to orchestrate multi-step flows and UI interactions to place an order.
- Tron-themed calculator: example of UI interacting with the conversation and triggering different system behaviors.
Hosts & projects to watch
- ChatGPT Apps (OpenAI): large reach; adopted MCP-like ideas and collaborated with MCPUI.
- Postman: supports MCP Apps.
- Cursor, VS Code (experimental), Goose (Block) — Goose is a desktop agent/CLI from Block that embraces MCP and was donated to the Linux Foundation.
- MCP Jam / Inspector: developer tooling to inspect and drive MCP servers locally.
- MCP and MCP Apps have been moved/donated into Linux Foundation stewardship to foster an open spec.
Where the ecosystem is headed
- Ongoing optimization to reduce context bloat (dynamic tool discovery, only provide relevant tool metadata post-prompt).
- Better DX: faster dev loops, HMR-like tooling, richer testing/evals.
- More hosts and consistent support for MCP Apps / MCP UI across major players.
- Continued blending of conversational agents and UI: widgets, sidecars, fullscreen app views (Zillow demo), richer two-way interactions—”put the application in the chatbot.”
- Long-term: agent memory, search, and progressive discovery will make agent interactions more human-like and efficient.
Actionable recommendations (for developers)
- Learn the basics of MCP: understand tool registration, schemas, and how hosts consume tool metadata.
- Start small: build a narrow, reusable MCP server (e.g., currency, calculator, personal dataset) and test against an inspector tool (MCP Jam/Inspector).
- Use static hosted assets for UI widgets and include CSP metadata as required by hosts.
- Implement dynamic discovery where possible to avoid context bloat — only send tool metadata relevant to the user’s prompt.
- Add evals for user-visible text: tool titles, descriptions, and prompts impact model behavior and deserve testing.
- Watch/spec: follow MCP, MCP Apps extension, and Linux Foundation repos; review examples from Sentry, Postman, and Goose for real implementations.
Notable quotes / insights
- “MCP is about eliminating the need to get things into the context window and then get things out of the context window back into the real world.”
- “It’s like the jQuery of context management — it normalizes differences across agents.”
- Tony Stark / Jarvis analogy: MCP + MCP UI = ability to build interactive assistants that change UI dynamically in response to instructions.
Resources & mentions
- Kent’s platforms: epicreact.dev, epicweb.dev, epicai.pro (Kent recommends these for learning React, full-stack, and AI with MCP)
- Projects & names to follow: MCP, MCP UI, MCP Apps, ChatGPT Apps, Goose (by Block), Postman MCP support, Sentry’s MCP server, MCP Jam / Inspector.
- Example use-cases to prototype: Media RSS, currency convertor, calculator widget, small CRUD-like widgets for your own app.
Kent’s “sick pick” & plug
- Sick pick: OneWheel (personal, fun hardware recommendation).
- Shameless plug: Kent’s learning platforms — epicweb.dev, epicreact.dev, epicai.pro.
Summary: MCP is maturing quickly — it standardizes model tool-calling and opens up the possibility for interactive UI embedded in agent conversations. The spec, tooling, and host support are still evolving, but practical, valuable use-cases already exist. Developers should start experimenting with small MCP servers, use local inspectors (MCP Jam), and design UIs as static, CSP-aware widgets that interact via tool calls.