In January 2026, Anthropic launched MCP Apps — an extension to the Model Context Protocol that allows MCP servers to render interactive UI components directly inside the AI assistant's interface. Instead of pure text responses, MCP servers can now return rich, interactive elements: buttons, sliders, dropdown menus, data tables, image previews, and even custom visual components.

This might sound like a small technical addition. It's not. For game developers using MCP-powered tools, MCP Apps fundamentally changes what's possible inside the AI conversation itself. Instead of describing a scene and hoping the AI interprets your intent correctly, you can interact with visual previews, tweak parameters through sliders, browse assets through thumbnail grids, and see structured data in sortable tables — all without leaving the conversation window.

This post explains what MCP Apps are, how they work, what they mean for game development workflows, and where we see them heading. We'll cover practical use cases, walk through how MCP servers like the Unreal MCP Server and Blender MCP Server could leverage this capability, and discuss the concept of building custom tool UIs inside your AI assistant.

What Are MCP Apps?

MCP Apps extend the existing Model Context Protocol with a UI rendering capability. In the standard MCP flow, an AI assistant calls a tool and receives a text response — structured data, status messages, confirmation of actions. With MCP Apps, that response can include interactive UI components that render directly in the chat interface.

Here's the conceptual flow:

Standard MCP:

1. User asks: "Show me all the lights in my scene"
2. Claude calls the MCP tool get_actors_by_class
3. Tool returns text: a list of actor names and properties
4. Claude presents the list as formatted text

MCP Apps:

1. User asks: "Show me all the lights in my scene"
2. Claude calls the MCP tool get_actors_by_class
3. Tool returns an interactive UI component: a sortable table with columns for name, type, intensity, color, radius
4. The table renders in the chat with clickable headers for sorting, selectable rows for batch operations, and inline editing for properties

The difference is interaction. With standard MCP, the data is static — you read it, then type a new message if you want to change something. With MCP Apps, the data is live — you can interact with it directly, and those interactions trigger further MCP calls without additional typing.

Technical Foundation

MCP Apps work through a defined component model. When an MCP server responds to a tool call, it can include a UI specification alongside or instead of text content. This specification describes:

• Component type — What kind of UI element (table, form, image grid, chart, custom component)
• Data binding — What data populates the component
• Interaction handlers — What MCP tools to call when the user interacts with the component (click a button, change a slider, select an item)
• Layout — How multiple components are arranged

The AI assistant client (Claude Desktop, Claude Code, or a third-party client) renders these components in its interface. The rendering is handled by the client, not the MCP server, so the server just describes what it wants displayed and the client figures out how to show it.

This client-side rendering model means MCP Apps look and feel native to whatever AI assistant you're using. They're not embedded web pages or foreign widgets — they're part of the conversation interface.

What MCP Apps Can Render

The current MCP Apps specification supports several component categories:

Data display components:

• Tables with sorting, filtering, and pagination
• Lists with selectable items
• Key-value property panels
• Charts and graphs (bar, line, scatter)
• Status indicators and progress bars

Input components:

• Text fields and text areas
• Number inputs and sliders
• Dropdowns and multi-select
• Checkboxes and toggle switches
• Color pickers
• File upload areas

Media components:

• Image display and grids
• Thumbnails with metadata overlays
• Before/after comparisons
• Preview windows

Layout components:

• Tabs and accordion panels
• Collapsible sections
• Split panes
• Grid layouts

Action components:

• Buttons (with MCP tool call bindings)
• Context menus
• Toolbars
• Confirmation dialogs

These building blocks, combined, allow MCP servers to construct fairly sophisticated interfaces inside the AI conversation.

Why This Matters for Game Development

Game development tools are inherently visual and interactive. You're working with 3D scenes, images, materials, particle effects, animations — things that are hard to reason about in pure text.

The standard MCP workflow, powerful as it is, has a fundamental limitation: everything passes through text. When Claude queries your scene through the Unreal MCP Server and reports "PointLight_03 has intensity 5000, color R=255 G=220 B=180, attenuation radius 500," you have to mentally translate those numbers into what the light looks like. If you want to change it, you type "reduce the intensity to 3000" and hope that's the right value.

MCP Apps collapse that translation gap. Instead of numbers describing a light, you could see:

• A color swatch showing the actual light color
• A slider for intensity that you drag to the desired value
• A visual radius indicator
• Real-time preview feedback as you adjust

This doesn't replace the conversational AI workflow — it augments it. You can still describe changes in natural language. But for parameters that are easier to see and adjust visually (color, numeric values, spatial layout), interactive UI components are faster and more intuitive.

The Conversation as Interface

There's a deeper conceptual shift here. Traditionally, game dev tools live in the engine's editor UI — Unreal's Details panel, its material editor, its level viewport. The AI assistant lives in a separate window. You type instructions in one window and watch results in another.

MCP Apps start to merge these contexts. Pieces of the engine's UI functionality — property editing, asset browsing, scene inspection — can surface inside the conversation. You don't need to switch to the Unreal Editor to adjust a material parameter if the material's properties are displayed as an editable panel right in your chat.

This doesn't mean the Unreal Editor becomes unnecessary. Complex spatial editing, viewport navigation, visual composition — these need a proper 3D viewport that MCP Apps can't replicate. But for data-centric operations (property editing, asset selection, batch operations, scene queries), the conversational interface with embedded UI components can be faster than context-switching to the editor.

Game Dev Use Cases for MCP Apps

Let's get concrete. Here are specific game development workflows that MCP Apps can improve, and how they might work in practice.

Use Case 1: Asset Browser Inside the Conversation

The problem: When placing assets through MCP, you need to know asset names. "Place SM_Rock_03 at position..." But what does SM_Rock_03 look like? You'd have to go to the Unreal Content Browser, find it, check the thumbnail, then come back to the conversation.

The MCP Apps solution: An asset browser component that renders thumbnails of available assets in a grid, directly in the chat. You search by name or tag, see visual thumbnails, and click to select. The selected asset name is automatically used in subsequent operations.

How it would work:

1. You ask: "Show me the rock meshes in my project"
2. The MCP server queries the content browser and returns a grid component with thumbnails and metadata
3. You see a visual grid of rock meshes — SM_Rock_01 through SM_Rock_12 — with poly count, dimensions, and material count under each thumbnail
4. You click SM_Rock_07 — it looks like the right shape
5. You type: "Place that one at the base of the cliff face, three instances with random rotation"
6. Claude uses the selection context to place SM_Rock_07

The visual browsing step eliminates the guesswork of working with asset names alone.

Use Case 2: Scene Hierarchy Explorer

The problem: Complex scenes have hundreds or thousands of actors. Querying the scene through text produces long lists that are hard to parse and navigate.

The MCP Apps solution: A collapsible tree view showing the scene hierarchy, similar to the Unreal World Outliner but embedded in the conversation. Actors are organized by folder or type. You can expand/collapse branches, select actors, and trigger operations on selections.

How it would work:

1. You ask: "Show me the scene hierarchy for the market area"
2. A tree view renders with top-level folders: Lighting, Buildings, Props, Vegetation, Audio
3. You expand "Props" — see 45 actors organized by type
4. You select all 12 barrel actors using checkboxes
5. You ask: "Move these 10cm to the right and vary their Z rotation by 0-360 degrees"
6. Claude operates on the selected set

The tree view gives you spatial awareness and selection capability that pure text can't match efficiently.

Use Case 3: Material Property Editor

The problem: Tweaking material parameters through text is slow and blind. "Set roughness to 0.6" — is that right? You can't tell until you look at the result in the viewport. You end up in a loop of "try a value, check the viewport, try another value."

The MCP Apps solution: A property panel with sliders, color pickers, and parameter inputs for the selected material instance. Changes through the UI trigger MCP calls that update the material in real time.

How it would work:

1. You ask: "Show me the material properties for MI_Wrought_Iron"
2. A property panel renders with:
   • Base Color: color picker showing (0.05, 0.05, 0.06)
   • Metallic: slider at 1.0
   • Roughness: slider at 0.7
   • Normal Intensity: slider at 1.0
   • Rust Amount: slider at 0.0
   • Tint: color picker showing neutral gray
3. You drag the Roughness slider to 0.5 — the MCP server updates the material in Unreal in real time
4. You adjust the Rust Amount slider to 0.3
5. You use the color picker to shift the tint slightly warmer

Each slider change triggers an MCP tool call that updates the material parameter. If you're watching the Unreal viewport on a second monitor, you see the changes in real time.

Use Case 4: Light Rig Dashboard

The problem: Lighting a scene involves coordinating multiple lights with many parameters each. Adjusting one light often requires compensating adjustments to others. Managing this through sequential text commands is tedious.

The MCP Apps solution: A dashboard showing all lights in the scene with key parameters visible at a glance. Inline editing for intensity, color, and radius. Batch selection for coordinated adjustments.

How it would work:

1. You ask: "Show me the lighting dashboard for this level"
2. A table renders with all lights:

   Name	Type	Intensity	Color	Radius	Shadows
   Sun	Directional	10.0	warm white	n/a	On
   SkyLight	Sky	1.0	blue	n/a	Off
   Lantern_01	Point	2000	orange	5m	On
   Lantern_02	Point	2000	orange	5m	On
   ...	...	...	...	...	...

3. You click the "Color" column header on any lantern row and get a color picker
4. You select all lantern lights and use a batch slider to reduce intensity by 20%
5. You toggle shadows off for the fill lights to improve performance
6. Each change applies through MCP in real time

Use Case 5: Scene Audit Report

The problem: QA audit results come back as long text lists. "Actor_037 has null mesh reference. Actor_128 is below minimum Z. Actor_241 has no collision..." Reading through 50 issues in a text block is slow and it's easy to miss things.

The MCP Apps solution: A structured report with severity-coded entries, sortable by category or severity, with action buttons for each issue.

How it would work:

1. You ask: "Run a full scene audit"
2. The MCP server runs the audit and returns a tabbed report component:
   • Tab 1: Critical Issues (3) — red indicators
   • Tab 2: Warnings (12) — yellow indicators
   • Tab 3: Info (8) — blue indicators
3. Each issue shows: actor name, issue description, suggested fix
4. Each issue has action buttons: "Fix Automatically" (for auto-fixable issues), "Select in Editor" (highlights the actor in Unreal's viewport), "Dismiss" (marks as accepted/won't fix)
5. You click "Fix Automatically" on the three critical issues — the MCP server applies the fixes
6. You click "Select in Editor" on the warnings to review them visually before deciding

The interactive report turns a passive text list into an actionable dashboard.

Use Case 6: Blueprint Configuration Panel

The problem: Configuring Blueprints through text requires knowing exact variable names and types. "Set the MaxHealth variable on BP_PlayerCharacter to 200" works if you know the variable exists and its type, but discovering what variables exist and what values make sense requires browsing the Blueprint editor.

The MCP Apps solution: A form-based property editor that shows all exposed Blueprint variables with appropriate input controls for their types.

How it would work:

1. You ask: "Show me the configuration for BP_PlayerCharacter"
2. A form renders organized by category:
   • Health: MaxHealth (number input: 100), HealthRegen (number input: 5.0), RegenDelay (number input: 3.0)
   • Movement: WalkSpeed (slider: 300-800, current: 600), SprintMultiplier (slider: 1.0-3.0, current: 1.5), JumpHeight (number input: 420)
   • Combat: BaseDamage (number input: 25), AttackSpeed (slider: 0.5-2.0, current: 1.0), CritChance (slider: 0-1, current: 0.05)
3. You adjust MaxHealth to 150 using the number input
4. You drag the SprintMultiplier slider to 1.8
5. Each change triggers an MCP call that updates the Blueprint default values

This is essentially a custom inspector panel generated on-the-fly from Blueprint metadata, living inside your AI conversation.

Use Case 7: Asset Pipeline Tracker

The problem: When running the Blender-to-Unreal pipeline across multiple assets, tracking which assets are at which stage, which have issues, and which are complete is difficult to manage in a text conversation.

The MCP Apps solution: A pipeline progress tracker showing all assets in the current batch with their pipeline stage and status.

How it would work:

1. You kick off a batch pipeline: "Import and set up these 8 market props from Blender"
2. A progress table renders and updates in real time:

   Asset	Model	UV	Materials	Export	Import	Setup	Status
   Barrel	Done	Done	Done	Done	Done	Done	Complete
   Crate	Done	Done	Done	Done	In Progress	-	Importing
   Sack	Done	Done	In Progress	-	-	-	Materials
   Basket	Done	In Progress	-	-	-	-	UV
   Bucket	In Progress	-	-	-	-	-	Modeling
   Lantern	Queued	-	-	-	-	-	Waiting
   Sign	Queued	-	-	-	-	-	Waiting
   Table	Queued	-	-	-	-	-	Waiting

3. Progress indicators update as each step completes
4. Failed steps highlight in red with an error message and "Retry" button
5. Completed assets show a "Preview" button that displays the asset thumbnail

This transforms a batch pipeline from an opaque process into a visible, manageable workflow.

Building MCP Apps: The Developer Perspective

If you're an MCP server developer (or interested in becoming one), here's how MCP Apps work from the development side.

The UI Specification Model

MCP Apps use a declarative UI specification. Rather than writing HTML or React components, you describe the UI structure in a JSON-like specification that the AI client renders:

The specification defines component types, their properties, data sources, and interaction handlers. The key principle is declarative: you say what you want displayed and what should happen on interaction, not how to render it.

Component Lifecycle

MCP App components have a simple lifecycle:

1. Initial render — The MCP server returns a UI specification in response to a tool call. The client renders it.

2. User interaction — The user clicks, drags, selects, or inputs. The client sends the interaction event back to the MCP server as a new tool call with context about what was interacted with and what the new value is.

3. Update — The MCP server processes the interaction (e.g., updates a material parameter in Unreal Engine) and returns either a confirmation, an updated UI specification, or both.

4. Re-render — The client updates the displayed component based on the response.

This cycle repeats for every interaction. The MCP server maintains state and the client maintains the visual representation.

Stateful vs. Stateless Components

Some components are stateless — they display data at a point in time and don't change. A scene audit report, for example, shows the results of a scan and doesn't update unless you re-run the scan.

Others are stateful — they maintain a connection to live data. A material property editor, for example, should reflect changes made in the Unreal Editor UI as well as changes made through the MCP Apps component. This requires the MCP server to track state and push updates.

Stateful components are more complex to implement but more useful for real-time workflows. Stateless components are simpler and appropriate for one-shot operations like reports and queries.

Integration with AI Conversation

A key design consideration: MCP Apps components exist within an AI conversation. They're not standalone applications. This means:

• The AI can reference and interact with the displayed components
• User interactions with components become part of the conversation context
• The AI can suggest interactions: "Try increasing the roughness to 0.8 — that might give you the worn look you described"
• Components and conversation text complement each other

This bi-directional integration — the AI aware of the UI and the UI feeding back into the AI conversation — creates a workflow that's more fluid than either pure text or pure GUI alone.

How StraySpark MCP Servers Could Leverage MCP Apps

We've been thinking about how the Unreal MCP Server and Blender MCP Server could leverage MCP Apps to improve their workflows. Here's our thinking.

Scene Visualization

The highest-impact addition would be scene state visualization. When Claude queries your scene through MCP, instead of returning text descriptions of actor positions and properties, it could return a structured visual representation — a 2D map view showing actor positions, a property panel for selected actors, and action buttons for common operations.

This wouldn't replace the 3D viewport — you'd still need Unreal's viewport for spatial editing and visual composition. But for operations that are primarily data-centric (finding actors, checking properties, batch operations), a visual representation inside the conversation would be faster than switching to the editor.

Tool Configuration Panels

Many MCP tools have parameters that affect their behavior. For example, the procedural placement tools have parameters for density, radius, slope filtering, and randomization. Currently, you set these through text instructions. With MCP Apps, these could be presented as a configuration panel with appropriate controls (sliders, dropdowns, checkboxes), making it faster to dial in the right settings.

Asset Pipeline Dashboard

For the Blender-to-Unreal pipeline described in our complete asset pipeline guide, a pipeline dashboard showing asset status, thumbnails, and stage progress would make batch operations much more manageable.

Debug and Diagnostic Views

When something goes wrong — a material isn't rendering correctly, an actor is in an unexpected state, a Blueprint has configuration issues — diagnostic data presented in structured tables and property panels is much easier to parse than raw text dumps.

Interactive Tutorials

MCP Apps could power interactive tutorials and guided workflows. Instead of reading instructions and typing commands, new users could follow a step-by-step guide with interactive elements: "Click this button to spawn your first actor. Now use this slider to adjust its height. Click here to apply a material."

The Bigger Picture: AI-Native Interfaces

MCP Apps represent a broader shift toward what we might call AI-native interfaces — UIs that are designed to exist within an AI conversation context, augmenting the natural language interaction with visual and interactive elements where they add value.

This is different from both traditional GUIs and traditional AI chat interfaces:

Traditional GUI: Complete, standalone interface. All interaction happens through the visual interface. No natural language component.

Traditional AI chat: Pure text interaction. All context must be conveyed through language. Visual and interactive elements are absent.

AI-native interface (MCP Apps): Hybrid. Natural language handles intent, direction, and complex instructions. Visual components handle data display, parameter tweaking, and selection. The two modes complement each other.

For game development, this hybrid approach makes a lot of sense. Some tasks are inherently conversational: "Set up moody lighting for a cave scene" is better expressed in natural language than through a form. Other tasks are inherently interactive: picking a color, adjusting a slider, selecting from a list of thumbnails. The best workflow uses the right modality for each task.

Where This Is Going

Looking ahead, we expect MCP Apps to evolve in several directions:

Richer visual components — 3D previews, animation timelines, node graph editors. The component library will expand to cover more of the visual vocabulary that game developers need.

Persistent dashboards — MCP App components that persist across conversations, maintaining a live view of project state. Currently, components exist within a single conversation turn. Persistent components would function more like traditional application panels.

Multi-user collaboration — MCP App components that multiple team members can see and interact with simultaneously, with changes synchronized through the MCP server. Imagine a shared material library browser or a scene audit dashboard that the whole team can act on.

Custom component development — The ability for MCP server developers to create custom visual components beyond the standard library. Game studios could build specialized components for their specific workflows — a custom level overview map, a proprietary asset management interface, a studio-specific QA dashboard.

Cross-application components — Components that display data from multiple MCP servers simultaneously. A pipeline dashboard showing Blender asset status and Unreal scene state side by side, for example.

The Spectrum of Complexity

Not every MCP Apps use case needs to be complex. Some of the most useful applications are simple:

• A confirmation dialog before a destructive operation: "You're about to delete 47 actors. Are you sure?" with Yes/No buttons. Better than hoping you read the text warning.

• A progress bar during long operations: importing 20 assets, running a scene audit, generating LODs for a batch of meshes. Better than staring at a text cursor wondering if it's still working.

• A selection list when the AI isn't sure which asset you mean: "I found 4 materials matching 'stone.' Which one?" with a list of names and thumbnails. Better than the AI guessing or asking you to be more specific in text.

• A results summary after a batch operation: "Updated 34 actors. 31 succeeded, 3 had issues." with a table of details. Better than a paragraph of text you have to parse.

These simple components, integrated naturally into the AI conversation flow, reduce friction at common interaction points. You don't need a full dashboard to benefit from MCP Apps.

Practical Considerations

Performance

MCP App components need to be responsive. A table that takes 3 seconds to render or a slider that lags when dragged defeats the purpose. This puts requirements on both the MCP server (fast data queries) and the AI client (efficient component rendering).

For the Unreal MCP Server, this means ensuring that scene queries used to populate MCP App components are optimized. Querying 5000 actors to populate a table should return in under a second, not ten seconds.

Context Window Impact

MCP App UI specifications consume context window space, just like text responses. A complex UI specification with 500 data rows is a lot of context. MCP server developers need to balance UI richness against context efficiency — paginate large datasets, lazy-load details on demand, summarize where possible.

Client Compatibility

Not all AI clients support MCP Apps, and those that do may support different subsets of components. MCP servers should degrade gracefully — if the client doesn't support MCP Apps, fall back to text responses that convey the same information.

Security Considerations

MCP App components that trigger MCP tool calls need the same security model as direct tool calls. A "Delete All Actors" button in a UI component should require the same confirmation as a text-based delete command. The UI layer shouldn't bypass safety checks.

Getting Started with MCP Apps

If you're interested in building MCP App components for your own MCP server, or exploring existing MCP servers that support them:

1. Check client support — Verify that your AI assistant client (Claude Desktop, Claude Code, etc.) supports MCP Apps rendering. Update to the latest version if needed.

2. Review the specification — The MCP Apps specification is part of the MCP documentation. It defines the component types, their properties, and the interaction model.

3. Start simple — Build a single stateless component first — a data table or a simple form. Get familiar with the specification and rendering model before building complex interactive panels.

4. Test across clients — If your MCP server is used with multiple AI clients, test that your components render correctly in each one. Rendering differences between clients are possible.

5. Gather user feedback — The most useful MCP App components are the ones that solve real workflow friction points. Talk to users of your MCP server about what operations they find tedious in text and would prefer to do visually.

Comparing MCP Apps to Traditional Plugin UIs

It's worth understanding where MCP Apps sit relative to existing UI paradigms in game development.

Unreal Engine Slate/UMG Widgets

Unreal's native UI frameworks (Slate for editor tools, UMG for game UI) are full-featured, performance-optimized, and deeply integrated with the engine. They handle everything from the Details panel to custom editor plugins to in-game HUDs.

MCP Apps is not a replacement for any of this. Slate and UMG will continue to be the right choice for custom editor tools, gameplay UI, and anything that needs direct access to engine rendering or tight integration with the editor framework.

MCP Apps fills a different niche: lightweight, conversation-contextual interfaces for AI-assisted workflows. You wouldn't build a full material editor as an MCP App. You would build a quick parameter tweak panel that lets you adjust three values without switching windows.

Web-Based Dashboards

Many game studios build web dashboards for project tracking, asset management, and build monitoring. These run in browsers, pull data from databases and APIs, and provide rich interactive interfaces.

MCP Apps is simpler in scope but more tightly integrated with the AI workflow. A web dashboard requires its own hosting, its own frontend codebase, its own authentication. An MCP App component is part of the MCP server and renders automatically in the AI assistant. For quick, contextual interfaces that augment an AI conversation, MCP Apps has less overhead. For comprehensive project management tools, web dashboards remain more appropriate.

Editor Utility Widgets in UE5

Unreal Engine 5's Editor Utility Widgets let you build custom editor tools with Blueprints — popup windows, property editors, batch operation tools. They're useful and accessible to non-programmers.

MCP Apps and Editor Utility Widgets could complement each other. An MCP App component might configure and trigger an Editor Utility Widget, combining conversational AI with purpose-built editor tools. "Show me the LOD generation widget for SM_Rock_07" could surface an Editor Utility Widget through MCP Apps, bridging the conversation and the editor.

The Key Differentiator

What makes MCP Apps unique is not the UI capability itself — all of the component types (tables, sliders, forms) exist in every UI framework. The differentiator is the context: these components live inside an AI conversation, are generated by AI tools, and feed back into AI-driven workflows. The AI is aware of the UI, and the UI feeds into the AI's understanding.

This conversational context is what enables workflows like: "Show me the material properties" → [interactive panel appears] → user adjusts roughness slider → AI notices the change → "That roughness value might be too low for a stone surface — outdoor stone typically ranges 0.6-0.9. Want me to suggest some values based on the reference material?"

The AI isn't just displaying a UI — it's participating in the interaction, adding value around the edges of the visual interface.

Practical Design Patterns for MCP App Components

If you're designing MCP App interfaces for game dev workflows, here are patterns that work well.

The Inspector Pattern

Show the properties of a selected entity in an editable form. This mirrors the Unreal Details panel or Blender Properties panel. Key principles:

• Organize properties by category (Transform, Rendering, Physics, Gameplay)
• Use appropriate input types (sliders for bounded values, color pickers for colors, dropdowns for enums)
• Show only the most commonly edited properties by default, with an "expand" option for advanced settings
• Include a "Reset to Default" button per property

This pattern works for actors, materials, Blueprints, lights, cameras — anything with configurable properties.

The Gallery Pattern

Display a grid of items with thumbnails and metadata. Used for asset browsing, variant selection, and search results. Key principles:

• Show thumbnails large enough to be useful (at least 128x128 equivalent)
• Include essential metadata under each thumbnail (name, type, poly count for meshes, resolution for textures)
• Support selection (single or multi-select depending on context)
• Include filtering and sorting controls
• Paginate rather than showing hundreds of items at once

This pattern works for content browser subsets, material libraries, mesh collections, and texture atlases.

The Diff Pattern

Show before-and-after comparisons for operations that change scene state. Key principles:

• Side-by-side or overlay comparison for visual elements
• Highlighted changes in data views (green for additions, red for removals, yellow for modifications)
• Summary statistics ("Changed: 12 actors, Added: 3 actors, Removed: 1 actor")
• "Accept" and "Revert" actions

This pattern works for batch operations, pipeline stage outputs, and automated fix previews.

The Workflow Pattern

Guide users through a multi-step process with progress indication and step-specific UI. Key principles:

• Clear step labels with progress indicator
• Each step has its own relevant UI (form, selection, confirmation)
• "Back" and "Next" navigation
• Summary at the end before final execution

This pattern works for asset import wizards, pipeline configuration, scene setup workflows, and batch operation configuration.

Conclusion

MCP Apps extend the Model Context Protocol from tool execution into visual interaction. For game developers using MCP servers like the Unreal MCP Server and Blender MCP Server, this means that the AI conversation window becomes more than a text channel — it becomes an interactive workspace where data display, parameter editing, asset browsing, and batch operations happen visually alongside natural language instructions.

The technology is new. The full potential won't be realized immediately. But the direction is clear: AI-powered game development workflows will increasingly combine conversational AI with interactive visual components, using whatever modality is most efficient for each task.

For MCP server developers, MCP Apps is an opportunity to make your tools more accessible and efficient. For game developers, it's a step toward AI workflows that feel less like typing commands and more like using a purpose-built tool — because inside the AI conversation, that's exactly what they are.

We're watching this space closely and thinking about how our MCP servers can leverage these capabilities to make game development workflows faster and more intuitive. The goal hasn't changed: build tools that let developers spend more time on creative decisions and less on mechanical execution. MCP Apps just gives us a richer vocabulary for achieving that goal.