Edt MCP Testing

EDT-MCP — manual e2e testing of tools

How to run each MCP tool live against a working EDT and confirm it actually works (not just compiles / passes a unit test). Build and unit tests are in edt-mcp-build-test; this is live e2e through real MCP calls. (The automated black-box suite is edt-mcp-e2e-testing.)

Structure

• references/<family>/<tool>.md — one reference per tool: purpose, exact call, expected result, gotchas.
• references/<family>/SETUP.md — shared family preconditions (what the family's tools can't be tested without).

Test bench (harness)

• Non-elevated EDT copy + workspace D:\WS\EDT; MCP listens on :8765. Deploy edits with pwsh D:\Soft\edt-redeploy.ps1 (build → kill EDT → swap bundle → -clean relaunch → wait for :8765). The script sometimes returns exit 1 yet prints MCP server UP on 8765 — that is success; check the port / get_edt_version, don't trust the exit code.
• Test base — the TestConfiguration project (in repo TestConfiguration/src, open in the workspace). Run destructive/mutating cases only on it; revert after: git checkout HEAD -- TestConfiguration && git clean -fd -- TestConfiguration.
• Workflow invariant: edit → bash source/compile.sh → redeploy → live MCP call → git diff → revert. After a -clean redeploy EDT loses unsaved in-memory changes — mutate through MCP (write_module_source etc.) so model and disk stay in sync.
• Flaky tool output: the channel sometimes drops text (you see a bare Error / Done instead of JSON). Re-verify state independently: debug_status, git status, Get-Process, and especially the EDT log D:\WS\EDT\.metadata\.log (it records the full request/response). Don't trust the echo.

How to add a tool reference

1. Run the tool live with real arguments on TestConfiguration.
2. Record the exact call + actual output + gotchas in references/<family>/<tool>.md.
3. Link the family SETUP.md.
4. If the run needs a base mutation — document it and the revert.

Index — debug (references/debug/)

• SETUP — bring up a debuggable scenario (executable code + trigger + stop).
• Configs/launch: list_configurations, launch, debug_status, terminate_launch.
• Breakpoints: set_breakpoint, list_breakpoints, remove_breakpoint.
• Break and inspect: wait_for_break, get_variables, evaluate_expression, step, resume.

Full debug flow: set_breakpoint → launch(update) → wait_for_break(hit) → get_variables → step over → get_variables → evaluate_expression → resume → remove_breakpoint. Details per tool in its reference.

Index — navigation / read (references/navigation/)

Read-only navigation and read tools, each with a real live call on TestConfiguration.

• SETUP — project ready (not building), BSL index built, modulePath addressing, UI-thread tools.
• Workspace/listing: list_projects, list_modules.
• Source: read_module_source, read_method_source, get_module_structure.
• AST/refs: go_to_definition, find_references, get_method_call_hierarchy, get_symbol_info, get_content_assist.

Index — metadata-read (references/metadata-read/)

Read-only reading of the configuration model (objects, details, properties, subsystems, tags). Each with a real live call on TestConfiguration.

• Objects: get_metadata_objects, get_metadata_details.
• Configuration: get_configuration_properties (YAML).
• Subsystems: list_subsystems, get_subsystem_content.
• Tags: get_tags, get_objects_by_tags.

Index — query / problems / misc (read-only)

• query (references/query/): validate_query (dialect-aware, valid:false ≠ failure).
• problems (references/problems/): get_project_errors, get_problem_summary, get_check_description (reads <checkId>.md from a configurable folder; the feature is OFF by default; checkId is sanitized — dotted codes don't resolve).
• misc (references/misc/): get_edt_version (TEXT, liveness probe), get_platform_documentation, get_markers, get_applications.

Index — profiling / forms / xml / translation / launch / metadata-write

Families with write/destructive/special setup. For mutating/destructive tools the docs describe the test procedure from source (mutate-then-revert / preview-then-confirm), without live destruction.

• profiling (references/profiling/): start_profiling (a TOGGLE; applicationId = the debug-session id, not the infobase GUID), get_profiling_results (read-only; returns only the most recent measurement session).
• forms (references/forms/): get_form_screenshot, get_form_layout_snapshot — need the JVM flag -DnativeFormBufferedLayoutRender=true; blank ≠ a bug; native vs buffered render.
• xml (references/xml/): export_configuration_to_xml, import_configuration_from_xml (MUTATES → revert).
• translation (references/translation/): get_translation_project_info (read-only), generate_translation_strings, translate_configuration (MUTATES + external providers).
• launch (references/launch/): update_database (DESTRUCTIVE, exclusive infobase access), run_yaxunit_tests, debug_yaxunit_tests.
• metadata-write (references/metadata-write/): create_metadata (FQN-addressed), modify_metadata (set properties=[{name,value,language?}] by FQN), write_module_source (mutate→verify→revert), rename_metadata_object, delete_metadata (FQN-addressed; CASCADE; preview→confirm→revert; explicit-request-only), adopt_metadata_object (adopt a base object/member into an extension; MUTATES→revert).

Coverage: debug + navigation, metadata-read, query, problems, misc, profiling, forms, xml, translation, launch, metadata-write = every MCP tool (62 today) has a per-tool e2e reference. Write/destructive tools document the procedure from source (mutate-then-revert / preview-then-confirm), not live destruction.