Cursor, VS Code, and Visual Studio Setup

Cursor, VS Code, and Visual Studio are easiest to configure from the JSON artifacts generated by the installer.

1. Install WPF DevTools

Published-release command after GitHub Release assets exist:

irm https://installer.wpf-mcptools.evanlau1798.com | iex

The HTTPS alias resolves scripts/online-installer.ps1; promote it only after the selected version has GitHub Release assets and sidecars: release_<version>_win-<arch>.zip, SHA256SUMS.txt, release-assets.json, release-sbom.spdx.json, and release-evidence.json.

Preferred local package path:

  1. Review scripts/online-installer.ps1 as the canonical source entrypoint.
  2. Run the reviewed installer against a verified local package archive.

Example:

powershell -ExecutionPolicy Bypass -File .\scripts\online-installer.ps1 -PackageArchivePath .\release\release_<version>_win-<arch>.zip -TrustedReleaseMetadataDirectory .\release -Client vscode -NonInteractive -Force -OutputJson

Package-local fallback:

  1. Use a locally generated package, or after GitHub Release assets exist, download the matching release_<version>_win-<arch>.zip from Releases together with SHA256SUMS.txt, release-assets.json, release-sbom.spdx.json, and release-evidence.json.
  2. Verify the archive with SHA256SUMS.txt, release-assets.json, and release-sbom.spdx.json before extraction.
  3. Extract the package.
  4. Run run.bat.

Before trusting the extracted package, keep the verified release sidecars beside the archive: SHA256SUMS.txt for the checksum, release-assets.json for the canonical release metadata, and release-sbom.spdx.json for the release asset SBOM. The SBOM sidecar is an asset-level release archive inventory, not a full package/dependency SBOM. Production payload signature verification still requires an independent WPFDEVTOOLS_RELEASE_SIGNER_THUMBPRINT; adjacent sidecars prove archive provenance but do not replace signer trust. WPFDEVTOOLS_RELEASE_SIGNER_SUBJECT is only an additional constraint after the thumbprint is pinned.

run.bat requests elevation when the current shell is not already elevated and then launches the packaged bin/install.ps1. Set WPFDEVTOOLS_SKIP_ELEVATION=1 when you need to keep the install in the current unelevated shell.

After installation, the fallback executable path when no previous live install root is reused is:

C:\Users\<you>\AppData\Roaming\WpfDevToolsMcp\<arch>\current\bin\wpf-devtools-<arch>.exe

2. Generated JSON artifacts

The installer writes editor-ready JSON files under client-registration\.

Cursor

Global profile

Use client-registration\cursor.global.json when you want a user-level Cursor registration. Copy the mcpServers.wpf-devtools node into:

%USERPROFILE%\.cursor\mcp.json

Its structure is:

{
  "mcpServers": {
    "wpf-devtools": {
      "type": "stdio",
      "command": "C:\\Users\\<you>\\AppData\\Roaming\\WpfDevToolsMcp\\<arch>\\current\\bin\\wpf-devtools-<arch>.exe",
      "args": []
    }
  }
}

Cursor project profile

Use client-registration\cursor.project.json when you want a repo-local Cursor registration shared through project files. Copy the same mcpServers.wpf-devtools node into:

<repo>\.cursor\mcp.json

Cursor editor workflows and Cursor CLI MCP workflows both read the same .cursor\mcp.json / %USERPROFILE%\.cursor\mcp.json configuration shape. Treat the generated client-registration artifact as the source of truth for the resolved executable path instead of the sample path above.

VS Code

Visual Studio uses the same generated servers JSON shape.

Use client-registration\vscode.json or client-registration\visual-studio.json. Their structure is:

{
  "servers": {
    "wpf-devtools": {
      "type": "stdio",
      "command": "C:\\Users\\<you>\\AppData\\Roaming\\WpfDevToolsMcp\\<arch>\\current\\bin\\wpf-devtools-<arch>.exe",
      "args": []
    }
  }
}

By default, the installer writes VS Code registrations to %APPDATA%\Code\User\mcp.json and Visual Studio registrations to %USERPROFILE%\.mcp.json. Use .vscode\mcp.json only when you intentionally want a manual project-scoped alternative. Treat the generated client-registration artifact as the source of truth for the resolved executable path instead of the sample path above.

Before the first workflow, confirm WPFDEVTOOLS_MCP_ALLOWED_TARGETS contains the reviewed target's exact local absolute executable path; unset or malformed values fail closed before connect attaches.

3. First useful workflow

  1. Run connect().
  2. If the client exposes prompts or resources, prefer those discovery surfaces over raw protocol bootstrapping.
  3. If auto-discovery reports multiple candidates, run get_processes(windowFilter) and retry connect(processId).
  4. Run get_ui_summary(depthMode: "semantic").
  5. Follow navigation.recommended first and use nextSteps as the compatibility field when the client does not surface navigation yet.
  6. Use get_visual_tree, or get_element_snapshot(elementId) after a concrete elementId is known, only if you still need deeper structure.

Notes

  • Cursor uses mcpServers; VS Code and Visual Studio use servers.
  • Re-register or refresh the editor config after switching architectures.
  • Cursor global and project registrations can coexist, but keep only one active wpf-devtools entry per scope.
  • Re-register the installed executable after switching architectures.
  • Keep editor-side wrappers from writing to stdout.
  • Prefer scene-level summaries before tree dumps in editor-driven workflows.
  • When a tool result already includes navigation.recommended or nextSteps, treat that runtime guidance as more reliable than a fixed manual checklist.