Show and tell: Persistent editor workflows in DeepSeek Harness with MCP Apps

[wangcan26]

I built an installable community plugin that adds an MCP Apps Host to DeepSeek Harness:

• Host: https://github.com/creativedswork/dsh-mcp-apps
• npm: https://www.npmjs.com/package/@creative-dswork/dsh-mcp-apps
• Three.js editor: https://github.com/creativedswork/threejs-editor-mcp
• Harness community discussion: 任何 Editor，皆可成为 DSH Editor：用 MCP Apps 打通编辑、保存与 Agent 回读 deepseek-ai/deepseek-harness#2424

Product idea

Every Editor. One DSH Editor.

DSH Editor is my shorthand for a specialized editor that runs inside the Harness Agent Chat with its original UI and data model. A user edits and saves; the Agent reads the saved project state and operation records, then continues from that revision.

I use MCP Apps as the shared contract between the editor, its MCP Server, and the Host.

Demo

In this 34-second recording, the Agent creates a Three.js Pong project. The user changes the table layout and camera inside the MCP App, then clicks Save. That action persists a new revision and sends a standard ui/message. The next Agent turn calls inspect_project, reads the two human operations, and responds with what changed.

Host implementation

I built the plugin with @modelcontextprotocol/ext-apps@1.7.5 for the MCP Apps 2026-01-26 specification. It runs as a Cordis bundle and connects to Harness through public plugin and Session APIs.

I run a test gate that covers:

• tools/list and tools/call
• resources/list and resources/read
• ui:// resources with text/html;profile=mcp-app
• ui/initialize, tool input/result notifications, and teardown
• App-originated tool and resource calls
• model-visible and app-only tool separation
• text-only ui/message handoff to the current Harness Session
• bounded JSON download through ui/download-file
• stdio and Streamable HTTP transports

I keep model-facing tool text separate from structured UI metadata. If a View cannot load, the tool row retains its plain text result.

Security boundary

I run the Harness UI and Sandbox Proxy on different loopback origins. Each View sits inside a double iframe with CSP and explicit sandbox attributes. I accept a bridge message only when both postMessage origin and frame source match. Host API routes reject cross-origin writes and cap body and metadata sizes.

Today, you can run the plugin on loopback Web with inline views. You reconnect MCP transports manually.

The security diagram and threat boundary are here:

https://github.com/creativedswork/dsh-mcp-apps#security-architecture

Try it

dsh plugin --profile web add @creative-dswork/dsh-mcp-apps

You can also run the standalone Counter Demo against the published Harness CLI without a neighboring Harness source tree.

I would value implementation feedback on:

1. capability advertisement for the bounded ui/message and download paths;
2. lifecycle behavior around View teardown and tool-list changes;
3. Host compatibility gaps that belong in the next conformance test pass.

The package is community-maintained and uses the MIT License.