Pluggable Widgets MCP for Agentic(Copilot) Development #1869
Conversation
…to mendix-widgets-mcp
…to mendix-widgets-mcp
…to mendix-widgets-mcp
| oldKey: string, | ||
| newKey: string | ||
| ): Promise<Omit<FileChange, "originalContent"> | null> { | ||
| const typingsPath = join(packagePath, "typings", `${this.getWidgetName(packagePath)}Props.d.ts`); |
There was a problem hiding this comment.
Typings are auto generated, so a safer way would be to run the generation using pwt when we add/remove properties.
| } | ||
|
|
||
| // Rename operations (similar structure but with find/replace logic) | ||
| private async renamePropertyInXml( |
There was a problem hiding this comment.
We probably never want to rename props as it causes major migration issues 🙈 At least till we have a migration API for renaming.
There was a problem hiding this comment.
I think we can modify and keep it as a guardrail, this can trigger a "Don't do it" logic we would like to provide.
That guardrail can also be added into PRD, but doesn't an mcp level intervention sound safer? It is indeed a critical knowledge not to rename properties.
| return group; | ||
| } | ||
|
|
||
| private createPropertyXmlObject(property: PropertyDefinition): any { |
There was a problem hiding this comment.
I think we can benefit from some kind of library that converts properties xml to some sort of json structure/AST and back. Co we can manipulate this simpler tree instead of doing magic on the pure XML tree. I believe @iobuhov already has this as he was experimenting with moving properties between XML and YAML formats.
| try { | ||
| const srcFiles = await readdir(srcPath); | ||
| for (const file of srcFiles) { | ||
| if (file.includes("editorConfig")) { |
There was a problem hiding this comment.
You can guess the name if you parse package json and get widgetName field + editorConfig + ".ts", same with preview files, widget xml, they all have the same pattern.
| ? "customWidget" | ||
| : "module"; | ||
|
|
||
| inspection.packageInfo = { |
There was a problem hiding this comment.
There are already utils for this in automation/utils, better to re-use those ones if we can.
Major enhancements to the MCP server for better AI assistance: Sampling API (Context Awareness): - Lets AI "preview" widget code before making changes - Provides overview, properties, and runtime samples via Resources API - Think: "Look under the hood before fixing" Prompts API (Guided Workflows): - 7 pre-built "recipes" for common tasks (add property, build, debug, etc.) - Step-by-step guidance prevents AI mistakes - Think: "IKEA instructions for widget development" Architecture Improvements: - Modular structure: sampling.ts, prompts.ts separate from helpers.ts - Better separation of concerns - Cleaner, more maintainable codebase Documentation: - Updated README with clear explanations - Added usage examples for new features - Included project structure overview These changes make the AI smarter and less likely to break widgets by providing context awareness and structured workflows.
| name: "propertyType", | ||
| description: "Type of property (text, boolean, integer, enumeration, expression, action, attribute)", | ||
| required: true, | ||
| schema: z.enum(["text", "boolean", "integer", "enumeration", "expression", "action", "attribute"]) |
There was a problem hiding this comment.
fix with correct property types
Pull request type
Description
Introduce the Mendix Widgets Copilot MCP server for the web-widgets monorepo. It enables AI-assisted discovery, property updates, build/test workflows, and safe multi-file edits with preview and rollback.
Discovery: list packages, inspect widgets (XML/TS/runtime).
Property management: add/rename properties with full XML → TS → runtime integration.
Build/QA: verify manifest versions, build widgets (with destination selection), run unit/e2e tests, generate translations.
Diff engine: preview changes, apply atomically with backups, rollback with tokens.
Safety: strict path/command/file validation, dry-run by default, backups.
Configuration is available via .cursor/mcp.json with optional MX_PROJECT_PATH.
It's a WIP.