Interesting. I believe we'll see some kind of official MCP server in the future.
However, this seems heavily "vibe-coded" and quite problematic, as it modifies the project .json files directly without going through the editor (as described here).
It appears to have started as a Read-only MCP, and now is branching into Editing/modifying projects (as seen by some commits fixing "breaking project" bugs).
Besides not syncing with the editor, this can cause all sorts of issues and project corruption. The MCP will modify things in an unsupported way, without proper checks or using supported APIs. (For example, in-editor event sheets are type-safe. If you're directly editing a project's .json file, you are one keystroke away from corrupting your project)
Before using this, make sure you're using git, since it's very likely that it will break/corrupt your project and you'll have to have some sort of rollback-and-retry process.
(edit: I looked into the source code, and it doesn't look good. It even has its own image pipeline that mimics the behavior of the construct editor. This can silently corrupt your project and lead you down a path where you're unaware of what went wrong. Personally, I think a MCP/skills that interacts with the editor through the browser would be a better approach atm.)
Personally, I just:
- Asked my coding agent to read the docs and create my own "Read-only Construct Skill" to read my project.
- Make projects mostly TypeScript-based. TypeScript is a very easy language for LLMs/agents to work with reliably without breaking the code. Construct's TypeScript support is phenomenal, as it provides all necessary type definitions.
- Still handle "editor-centric" tasks myself, although you can let your agents use Playwright/Browser MCPs for some limited, repeatable tasks.