MCP tool: workspace_edit — modify components and write back to XML

[TomProkop]

Summary

New MCP tool for modifying workspace components and writing changes back to disk via XmlWorkspaceWriter. Full roundtrip: load → edit in-memory → write back.

API

workspace_edit (DESTRUCTIVE — agent must request confirmation)

Params:
  path:       string?  — path to workspace (default: cwd)
  type:       string   — component type
  id:         string   — component identifier
  operations: [{
    action:   string   — add-control, remove-control, move-control, set-label, add-attribute, ...
    target:   string   — path within component (tab/section/control id)
    params:   object   — action-specific parameters
  }]

Returns:
  modified_files: [string]  — list of changed files

Depends on (platform-metadata)

• IWorkspaceContext interface + implementations platform-metadata#60 — IWorkspaceContext (TransactionalContext for safe writes)
• Component builders — EntityBuilder + FormBuilder fluent API platform-metadata#62 — Component builders (FormBuilder, EntityBuilder)
• MergeableNode manipulation API — tree search and edit operations platform-metadata#63 — MergeableNode manipulation API

Implementation notes

• Use TransactionalContext for buffered writes with rollback on failure
• Use FormBuilder / EntityBuilder for type-safe manipulation
• Roundtrip-safe via XmlWorkspaceWriter — preserve unknown XML, zero diff on untouched files
• Marked as destructive in MCP — agent asks user for confirmation before executing

[Ram9199]

I am collecting real-world incidents around MCP tools that can modify durable workspace state.

Was marking workspace_edit as destructive and requiring confirmation driven by an actual incident/near miss, or preventive hardening? What changed afterward - transactional writes, manual approval, sandboxing, audit logs, split credentials, or no change?

Not asking about any product. I am trying to understand what behavior changes when MCP tools gain write authority.