[MCP host] Build a desktop chat with curated engineering tools and an optional Canvas #48

Product outcome

Casys Digital Thread is a downloadable desktop workspace for engineering: a normal chat, a curated MCP catalogue, several conversations within each project, and one optional shared Canvas per project.

Latest user decision, 2026-09-30: tool configuration and Canvas belong to the project, not an individual conversation. The application owns the catalogue, installation/preparation and shared local runtimes. A user enables Build123d once for a project and can use it from that project's current and future chats.

A project can start from a name and plain-language intention at any engineering stage. An approved brief, SysML model or linear questionnaire is not a prerequisite for useful ordinary MCP work. Existing standalone conversations remain readable and can join a project explicitly without losing artifacts.

Identity and authority

Reuse the existing server-owned EngineeringProject created by project_start from sourced intent. Do not introduce a competing lightweight project id or fabricate approved project state. Desktop stores operational tool settings and Canvas presentation metadata associated with this id; it owns native commands. Workbench remains a read-only GET/SSE projection.

Direct tool results are useful session work immediately. Project association or Canvas placement does not publish canonical Thread evidence, authorize engineering MRTR, or allow caller-selected registered engineering runtimes. Archived inputs/results/viewerIds and exported bytes retain their original conversation provenance.

Agent choice

Use Codex via ACPX to qualify the present first real journey. Keep agents selectable through #58 and retain the user's chosen default. Muse is a separate selectable profile whose real turns require their own qualification; users never need credentials for an unused agent. The workspace and catalogue are independent of the selected agent.

Delivery slices

• [MCP host] Open project workspaces with multiple conversations from first intent #61: project home/navigation and creation from first intent, with multiple conversations.
• [MCP host] Configure engineering MCP tools once per project #62: project-owned effective MCP tool set, reusing application catalogue/preparation [MCP host] Choose engineering tools from a curated catalogue inside any chat #54/[MCP host] Prepare and manage the selected tool runtime with or without Docker installed #56 and lifecycle [MCP host] Manage local ports and stop idle tool runtimes automatically #57.
• [MCP host] Share one engineering Canvas across a project’s conversations #55: one shared project Canvas, showing exact results from its multiple conversations.
• [MCP host] Attach existing chats and Canvas work to projects without losing artifacts #63: explicit attachment/migration of existing conversation and Canvas work without losing source/result/export bytes.
• [Desktop UI] Reuse a maintained chat UI library over the existing ACP host #64: reuse a maintained chat UI library through an existing-host adapter. assistant-ui is the initial candidate; Preact/native compatibility is a gate, not an assumed result.
• [MCP host] Use the provider's MCP App viewer in a standalone session #50: actual provider MCP App pixels and owning-session interactions.
• [MCP host] Save and reopen source, results and viewers without rerunning tools #51: durable original sources, results and exports, including offline reopen.
• [MCP host] Select ACP agents and preserve conversation work #58/[MCP host] Muse adapter does not forward MCP tool outputs (no viewers/archives) #59: agent selection and exact MCP output capture independently of adapter presentation.
• [MCP host] Download Casys and reach a saved Build123d result without manual Docker setup #53: complete install/setup/native user journey on the first supported target.

Completed #49/#54/#52 describe the earlier conversation-level baseline. Their closure does not prove the new project-owned experience. This revision supersedes those ownership assumptions without discarding their useful components or historical evidence.

First acceptance journey

“Pièce test” → enable Build123d once → first chat creates a part → second chat modifies or explores it → place both exact results on the common Canvas → export → close/reopen.

• Project creation and ordinary zero-tool chat work before engineering engine setup; no invented brief or model.
• Current and future conversations inherit the selected project tools; changing projects cannot mix settings, artifacts or runtime contexts.
• Chat and Canvas are views of the same project; result identities and originating conversation remain accessible.
• Complete the real Build123d create/view/edit/export/reopen sequence through the native application with the identified selected agent.
• Retain existing work and permit explicit project attachment, including old conversation Canvases; referenced bytes survive relevant retention/pruning.
• Prove application-managed setup on both supported no-Docker and compatible-existing-Docker paths; publish actual OS/CPU/agent versions and prerequisites.
• Use normal chat controls without presenting transport telemetry as assistant prose or adding file affordances without host support.
• Existing engineering projects and authoritative evidence remain readable under their actual identities.
• Record steps, elapsed time, confirmations and terminal interventions; public download/README claims match shipped and tested behavior.

Scope control

One complete Build123d project journey on one supported desktop target comes first. SPICE #47 is the next independent MCP recipe. A marketplace, full fleet install, universal workflow engine, all OS packages and qualification of every ACP adapter are not prerequisites. #6 owns optional explicit viewer-selection handoff and #22 concerns an external Codex host; both remain distinct.