ditrixnew/edt-mcp/edt-mcp-project-forms

EDT-MCP managed forms

Purpose and trigger

Use this skill to inspect or change a managed form's structure, data, commands, handlers, dynamic lists, or visible layout.

Operating rule

Read and apply the common operating rules before this workflow.

Task boundary

Work on the exact project and form FQN through structured EDT-MCP operations. Route code-only fixes to edt-mcp-project-local-fix and DCS changes to edt-mcp-project-query-dcs. Direct Form.form editing is a last resort only when the installed project rules describe the procedure, structured operations cannot represent the change, and the user explicitly authorizes the risk.

Primary workflow

1. Read the form with get_metadata_details and inspect only relevant handlers

with get_module_structure and read_method_source.

1. Consult the current guide, then use the narrowest supported

create_metadata, modify_metadata, or delete_metadata operation.

1. Re-read the form and verify the requested ownership, binding, data-path,

command, and handler relationships; validate changed query text with validate_query when applicable.

1. For a dynamic list, verify its owning form attribute, main table or custom

query, selected fields, visible item data paths, settings/filter handlers, and refresh/requery behavior. Validate changed query text before writing and ensure every visible List.Field path resolves afterward.

1. Use get_form_layout_snapshot when layout structure matters and

get_form_screenshot only when rendered appearance is acceptance evidence. get_form_screenshot is disabled by default; if it is not in tools/list, report visual evidence as unavailable. When taking a post-change screenshot, use refresh=true. Blank output most likely means EDT lacks -DnativeFormBufferedLayoutRender=true; report visual evidence as unavailable rather than treating the change as failed.

1. Run targeted validation and an authorized runtime UI scenario only when

interaction behavior must be proven.

Authority rule

Do not broaden a form mutation, leave dangling bindings, activate UI, launch a client, or change runtime data without the authority required for that effect.

Stop rule

Stop when the form target is ambiguous, the structured writer cannot represent the requested change, required references cannot be preserved, or necessary visual/runtime evidence is unavailable.

Completion signal

Return the exact form target, confirmed structural/source diff, targeted validation, requested layout or runtime evidence, and explicit gaps. A model read or screenshot proves only the state it actually reports, not user interaction.