XamlMcp

XamlMcp

XamlMcp は、Avalonia、WPF、WinUI 3、.NET MAUI 向けのオープンソース XAML MCP サーバーおよび AI 検査ツールキットです。Claude Code、Codex、GitHub Copilot、その他の MCP クライアントが、実行中のアプリケーションを検査および操作できるようにします。ビジュアルツリーまたは論理ツリーの走査、プロパティの読み書き、スタイルとリソースの検査、スクリーンショットの取得、入力の送信、コマンドとオートメーションパターンの呼び出し、認証されたローカルトランスポート上での変更の監視が可能です。

対応フレームワークおよび AI クライアントごとの集中的なセットアップ手順については、XamlMcp のインストールと構成ガイド を参照してください。

現在のリリースは 1.0.0-preview.3 です。Avalonia、モダン .NET WPF、自己完結型のアンパッケージ WinUI 3、および Windows と Android 上の .NET MAUI をサポートします。プロトコルバージョン 2 は安定しています。ネイティブ MAUI ノード、iOS、Mac Catalyst はサポートされていません。

ユーザー向けのリリース履歴については 変更履歴 を、ツールごとのサポートと機能限界については フレームワーク機能およびツールマトリックス を参照してください。プレビューリリースガイド では、パッケージの役割、インストールオプション、検証コマンドについて説明しています。

パッケージ

パッケージ	内容
XamlMcp.Avalonia	Avalonia アプリ用のインプロセスエージェント（net8.0、Avalonia 11.3.18+ および 12.x）
XamlMcp.Wpf	モダン .NET WPF アプリ用のインプロセスエージェント（net8.0-windows）
XamlMcp.WinUI	アンパッケージ WinUI 3 アプリ用のインプロセスエージェント（Windows App SDK 2.3.1）
XamlMcp.Maui	.NET MAUI 10.0.80 用の論理エージェント（net10.0、Windows、Android API 24+、スクリーンショットには API 26+ が必要）
XamlMcp.Windows.Input	Windows フレームワークエージェントが使用する共有のガード付き Win32 生入力コア
XamlMcp.Agent.Hosting	フレームワークに依存しないデスクトップ検出、認証、名前付きパイプホスト
XamlMcp.Protocol	共有 JSON-RPC コントラクト — DTO とフレーミング。UI フレームワークへの依存はありません
XamlMcp.Server	Stdio MCP サーバー: AI クライアントを実行中のエージェントに接続する xamlmcp という名前の dotnet tool

インストール

前提条件: 検査するアプリは .NET 8 以降をターゲットにできますが、xamlmcp ツール（およびこのリポジトリやサンプルをソースからビルドする場合）には .NET 10 SDK/ランタイム が必要です。

UI フレームワークに対応するエージェントパッケージを追加します:

dotnet add package XamlMcp.Avalonia --version 1.0.0-preview.3
dotnet add package XamlMcp.Wpf --version 1.0.0-preview.3
dotnet add package XamlMcp.WinUI --version 1.0.0-preview.3
dotnet add package XamlMcp.Maui --version 1.0.0-preview.3

エージェントの下限は Avalonia 11.3.18 です。プロジェクトが古い参照を固定している場合（現在の avalonia.app テンプレートは 11.3.0 を固定しています）、復元は NU1605 パッケージダウングレードエラーで失敗します — Avalonia.* パッケージ参照を少なくとも 11.3.18 に更新してください。

MCP サーバーツールをインストールします:

dotnet tool install --global XamlMcp.Server --version 1.0.0-preview.3

グローバルインストールなしでサーバーを実行することもできます:

dnx [email protected]

Avalonia エージェントのアタッチ

2 つのエントリポイントが明示的な診断オプトインを提供します。ビルドごと（オプション B）または起動ごと（オプション A）にエージェントを有効にしない限り、何もリッスンしません:

using XamlMcp.Avalonia;

// Option A - fluent, in BuildAvaloniaApp. Compiled in, but INERT unless the
// XAML_MCP=1 environment variable is set when the app launches.
public static AppBuilder BuildAvaloniaApp()
    => AppBuilder.Configure<App>()
        .UsePlatformDetect()
        .AttachXamlMcp();

// Option B - on the Application instance (e.g. in OnFrameworkInitializationCompleted).
// Marked [Conditional("DEBUG")]: the CALL SITE disappears from YOUR Release builds.
public override void OnFrameworkInitializationCompleted()
{
    this.AttachXamlMcp();
    base.OnFrameworkInitializationCompleted();
}

なぜ 2 つの形式があるのでしょうか？ [Conditional] は void メソッドを必要とするため、流暢な AppBuilder オーバーロードはこれを使用できず、代わりに環境変数でゲートします。また、パッケージ内で単純な #if DEBUG を使わないのはなぜでしょうか？ それは このパッケージ がパック時にどのようにコンパイルされたかでゲートされ、あなたの アプリの構成をまったく見ることができません。どちらのオーバーロードも、代わりにビルド構成または起動環境でゲートします。

違いを理解してください: オプション B の呼び出しは Release バイナリから 消えます。オプション A のコードは Release に含まれますが、起動時に XAML_MCP=1 が存在しない限り不活性のままです — 起動環境を制御する誰でもこれを有効にできます。流暢な形式で完全に除外する必要がある場合は、.AttachXamlMcp() の行を独自の #if DEBUG で囲んでください。

WPF エージェントのアタッチ

OnStartup 内で WPF の Application に対して拡張メソッドを呼び出します:

using System.Windows;
using XamlMcp.Wpf;

public partial class App : Application
{
    protected override void OnStartup(StartupEventArgs e)
    {
        this.AttachXamlMcp();
        base.OnStartup(e);
    }
}

WPF のメソッドは [Conditional("DEBUG")] であるため、呼び出しサイトは消費側アプリの Release ビルドから消えます。環境で有効化する WPF オーバーロードはありません。エージェントはアタッチを実行する Application.Dispatcher を使用します。セカンダリ WPF UI スレッドが所有するウィンドウとコントロールは除外されます。

WinUI エージェントをアタッチする

WinUI UI スレッド上でアタッチし、各 Window を明示的に登録し、呼び出しをアプリケーションの診断ビルドゲート内に保ってください：

using Microsoft.UI.Xaml;
using XamlMcp.WinUI;

public partial class App : Application
{
    private WinUiXamlMcpSession? _xamlMcp;
    private IDisposable? _windowRegistration;

    protected override void OnLaunched(LaunchActivatedEventArgs args)
    {
        var window = new MainWindow();
#if DEBUG
        var session = WinUiXamlMcp.Attach();
        _xamlMcp = session;
        _windowRegistration = session.RegisterWindow(window);
        window.Closed += async (_, _) =>
        {
            _windowRegistration?.Dispose();
            await session.DisposeAsync();
        };
#endif
        window.Activate();
    }
}

Attach() は条件付きコンパイルされません。呼び出し側が #if DEBUG または同等の診断ゲートを所有します。1 つのセッションは 1 つの DispatcherQueue と、そのキュー上で明示的に登録されたウィンドウをサポートします。サポートされる下限は Windows App SDK 2.3.1、ターゲットフレームワーク net8.0-windows10.0.19041.0、Windows 10 1809 (10.0.17763.0)、および win-x64 です。

WinUI のサポートは非パッケージです。WindowsPackageType=None、WindowsAppSDKSelfContained=true を使用し、新しいディレクトリに発行してください：

dotnet publish MyWinUiApp.csproj -c Release -r win-x64 --self-contained true -o artifacts/winui

発行出力は、生成された .xbf および .pri リソースを保持する必要があります。MSIX/パッケージ ID、証明書、Store 配布、XAML Islands、および複数の UI スレッドはサポートされていません。

.NET MAUI エージェントをアタッチする

MAUI アプリをビルドする際に、アプリケーションの診断ビルドゲート内で UseXamlMcp() を呼び出してください：

using XamlMcp.Maui;

public static MauiApp CreateMauiApp()
{
    var builder = MauiApp.CreateBuilder()
        .UseMauiApp<App>();

#if DEBUG
    builder.UseXamlMcp();
#endif

    return builder.Build();
}

同じパッケージと UseXamlMcp() 呼び出しは、非パッケージの Windows アプリケーションおよび MAUI 10.0.80 上のデバッグ可能な Android アプリケーションで動作します。パッケージは消費側の設定を検査しないため、呼び出し側が #if DEBUG または同等の診断ゲートを所有する必要があります。Android プロジェクトでは SupportedOSPlatformVersion を 24.0 以降に設定する必要があります。スクリーンショットには API 26 以降が必要です。

Windows では、エージェントは %LOCALAPPDATA%/XamlMcp/instances/ の下に検出ファイルを書き込み（ディレクトリは XAML_MCP_DIR で上書きできます）、現在のユーザーの名前付きパイプ上で JSON-RPC 2.0 を提供します。Android では、デバイスのループバックのみで待ち受け、起動ごとの記述子をアプリ専用ストレージに保存します。サーバーはデバッグ可能な run-as アクセスを通じてその記述子を読み取り、接続中のみ所有する adb forward を作成します。どちらのトランスポートも、いかなる検査呼び出しの前にも起動ごとのトークンを必要とします。

Android アプリを検出するには、そのアプリケーション ID を MCP サーバーに渡します。複数の承認済みデバイスがオンラインの場合、デバイスを明示的に選択してください：

claude mcp add xamlmcp -- xamlmcp --android-package dev.example.app --android-device emulator-5554

Windows ビルドの前提条件は .NET 10 SDK と MAUI Windows ワークロードです。Android にはさらに .NET Android ワークロードと Android SDK プラットフォームツール（adb）が必要です。iOS と Mac Catalyst はサポートされていません。

AI クライアントを接続する

XamlMcp はローカルの stdio MCP サーバーです。Claude Code または Codex は、クライアントセッションが必要としたときに起動します。常駐するサーバープロセスを実行する必要はありません。

このリポジトリには、両方のクライアント向けのポータブルなプロジェクト設定が含まれています：

• .mcp.json は Claude Code を設定します。
• .codex/config.toml は、信頼されたチェックアウト内で Codex を設定します。

どちらの設定も、固定されたプレビューを dnx を使って NuGet から直接実行するため、.NET 10 SDK が必要ですが、グローバルツールのインストールは不要です。リポジトリをクローンした後、新しいクライアントセッションを開いて登録を確認してください：

claude mcp get xamlmcp
codex mcp get xamlmcp

固定されたプレビューをユーザーアカウントに、または別のプロジェクトから登録するには、次を実行してください：

claude mcp add --scope user xamlmcp -- dnx [email protected]
codex mcp add xamlmcp -- dnx [email protected]

あるいは、ツールをグローバルにインストールし、その xamlmcp コマンドを登録します：

dotnet tool install --global XamlMcp.Server --version 1.0.0-preview.3
claude mcp add --scope user xamlmcp -- xamlmcp
codex mcp add xamlmcp -- xamlmcp

クライアントにすでに xamlmcp という名前のサーバーがある場合は、新しいエントリを追加する前にそのエントリを削除または更新してください。適宜 claude mcp remove xamlmcp --scope <local|user|project> または codex mcp remove xamlmcp を使用してください。

次に、インストルメント化されたアプリケーションを起動します。Avalonia の fluent アタッチ形式を使用する場合は XAML_MCP=1 を設定してください。その後、クライアントに list-apps → attach(instanceId) → 以下の任意のツールを呼び出すよう依頼してください。整数 PID によるアタッチは、Windows デスクトップの互換パスとして引き続き利用できます。

ツール	目的
list-apps	実行中の計測対象アプリ（不透明なインスタンス ID、プラットフォーム、サニタイズされたメタデータ。デスクトップエントリには pid も含まれます）
attach	1 つのアプリに接続し、ツールごとの機能フラグを報告します
detach	現在のアプリ接続とそのトランスポートリソースを解放します
tree	ビジュアル/論理ツリーのスナップショット。ノード ID の取得元です
search	オートメーション ID / 型 / 名前 / スタイルクラス / 擬似クラス / テキストでノードを検索します
ancestors	ノードの祖先チェーン
props	値、ソース/優先度、オートメーションパターン、コマンドスロットを持つプロパティ
set-prop	プロパティを書き込む、またはローカル値をクリアします（unset）
styles	適用されたスタイルセレクターとセッター（機能制限あり）
bindings	アクティブなバインディング、ソース/パス/ステータス/エラー、DataContext の由来、テンプレートの識別情報
failures	オプションのアクション相関カーソル以降に観測された、範囲が限定されたバインディング/ディスパッチャーの失敗証跡
resources	ノードまたはアプリスコープで可視の解決済みリソース
pseudo-class	:pointerover、:pressed などを切り替えます
screenshot	ウィンドウまたはノードの PNG。オプションで同一キャプチャのノードマップ付き — 実際の MCP 画像として返されます
wait-for	存在、可視性、有効/フォーカス状態、またはプロパティ述語を範囲付きでポーリングします
hit-test	論理座標における最深優先のビジュアルスタック。ノード参照とスケーリング付き
input	合成されたクリック、キー、テキスト、ホイール
action	オートメーションパターン（invoke/toggle/select/…）とバインドされた ICommand
assets	不透明なフレームワークアセット識別子（avares://、WPF pack、xamlmcp-asset:///、または maui-asset:///）を列挙します
open-asset	アセットを読み取ります（画像は画像として、テキストはテキストとして）
dialog-wait	ドライバー、オプトイン: アプリが開いたネイティブダイアログ（ファイルピッカー、メッセージボックス）を待機します
dialog-act	ドライバー、オプトイン: それに対して操作します — set-file-name、accept、cancel、select-button
window-list	ドライバー、オプトイン: アプリのトップレベルウィンドウとその状態および境界
window-act	ドライバー、オプトイン: ウィンドウを activate / move / resize / close します

AI クライアントの作者が知っておくべき 3 つのこと:

• ターゲティング: ノードツールは、正確な {snapshotId, nodeId} ターゲット、または automationId、name、type、text、styleClass を使ったロケーターを受け付け、オプションで within によってスコープを限定できます。ロケーターは nth が明示されていない限り一意に解決される必要があり、曖昧な場合はノードを暗黙に選択する代わりに型付きの候補を返します。

• 観測: すべての変更系ツール（set-prop、pseudo-class、input、action）は セトルウィンドウ（デフォルト 250 ms）を待機し、何が変更されたかのダイジェストを返します。高速な 連続操作には settleMs: 0 または observe: false を渡してください。Avalonia と WPF では、同じ結果に failureCursor が含まれます。それを failures に渡すと、そのアクション以降に観測されたバインディングまたはディスパッチャーの失敗のみを取得できます。オプションの正確な categories がページをフィルタリングします。truncated が true の場合、nextCursor を渡し戻すことで、証跡をスキップせずに次のページを取得できます。カーソルはデタッチまたは置き換えで失効します。

• スナップショット: 正確なノード参照は、ノードが存続している間、現在および直前 3 つのスナップショットにまたがって使用可能です。再クエリに耐える必要があるワークフローにはロケーターを使用してください。stale-snapshot または stale-node エラーは、ターゲットを再度解決する必要があることを意味します。

WPF 機能に関する注意事項

• tree、型/名前/テキストの search、ancestors、プロパティ、リソース、スクリーンショット、ルーティング入力、 アクション、オブザベーション、およびパッケージ化されたアセットは有効化されており、実機で検証済みです。
• WPF には Avalonia のようなクラスや疑似クラスのコレクションはありません。スタイルクラス/疑似クラスの検索および pseudo-class の変更は unsupported-capability を返します。
• styles は有効化されていますが、意図的に縮退しています。WPF が公開するのは宣言されたスタイル、セッター、トリガー、 および値ソースであり、適用された完全なセレクターカスケードではありません。結果内の degraded および degradationReason を参照してください。
• bindings は有効化されています。単純および複合バインディング宣言、現在のステータスと 検証エラー、DataContext の継承、テンプレート化された親、および名前付きのコントロール/コンテンツ/アイテム/ヘッダー テンプレートスロットを報告します。WPF は、アプリケーションコードに直接エスケープするコンバーター例外を保持しません。 バインディング式に表れるコンバーターの失敗は converter-error として報告されます。
• failures は有効化されており、範囲を限定したバインディングトレースおよびディスパッチャー例外の証拠をキャプチャします。 キャプチャは最初の変更または failures クエリの前にのみ開始され、既存の WPF トレースリスナーを保持し、 ディスパッチャー例外を処理済みとしてマークしません。WPF は、公開 API では元に戻せないプロセス全体のトレース リフレッシュを必要とします。デタッチは XamlMcp のリスナーを削除し、そのソースレベルを復元しますが、 フレームワークの内部トレースインフラストラクチャはそのプロセスに対して初期化されたままになります。
• ルーティング入力は WPF イベントを発生させ、メカニズム routed を報告します。物理的なマウス、 フォーカス、キャプチャ、または Mouse.DirectlyOver との等価性を主張するものではありません。空でない modifiers は unsupported-capability を返します。これはルーティングイベントの構築では修飾子の状態を注入できないためです。 input-raw は false です。公開されている InputManager.ProcessInput の証明もそれらの要件を満たさなかったためです。
• WPF のスクリーンショットは RenderTargetBitmap を介してレンダリングされます。別個のポップアップは、それぞれ自身の ツリー参照によってキャプチャする必要があります。ネイティブの子 HWND および GPU/エアスペースのコンテンツは、そのレンダリングの対象外です。
• assets は SDK が生成した *.g.resources を列挙し、それが発行した識別子のみを開きます。これは コンパイラーの慣習です—WPF には公開されたパッケージリソース列挙 API がありません—また、通常コピーされた Content ファイルは公開されません。

WinUI 機能に関する注意事項

• ビジュアル tree、型/名前/テキストの search、祖先、リソース、スクリーンショット、セマンティックアクション、 コマンドスロット、非パッケージ資産、および範囲を限定した観察が有効化されており、実機で検証済みです。
• tree.logical=false および props.complete=false です。プロパティの列挙には、ドキュメント化された既知の 依存関係プロパティカタログを使用します。それ以外の読み取りと書き込みは、完全性の主張ではなく、型付きエラーを返します。
• styles は有効ですが、WinUI が完全に適用されたセレクターカスケードを公開しないため、機能が低下しています。スクリーンショットには RenderTargetBitmap を使用します。ネイティブ HWND、airspace/GPU コンテンツ、および個別のトップレベルサーフェスには、ドキュメント化されたレンダリング制限が残ります。
• input は mechanism: "raw" の場合にのみ有効です。ルーティングされたインジェクションは unsupported-capability を返します。raw のクリック、移動、ホイール、キー、およびタイプは、ガード付きの SendInput を使用します。 登録された所有者は正確にフォアグラウンドのルートでなければならず、ポインター座標は依然として その HWND に解決される必要があり、明示的なキーボードターゲットはフォーカスを受け入れる必要があります。これらのチェックとインジェクションは アトミックではないため、raw 入力は明示的に有効化された診断セッション専用です。
• 疑似クラスの変更、およびスタイルクラス/疑似クラスの検索は無効のままです。ビジュアル状態は 疑似クラスとして提示されません。
• bindings は無効であり、unsupported-capability を返します。WinUI は、完全な公開検査 API を通じて 必要なバインディング式グラフを公開しません。
• failures は、同等の公開フレームワーク証拠が M38 で実装されるまで無効です。
• 資産は非パッケージアプリケーションディレクトリをルートとし、不透明な xamlmcp-asset:/// 識別子を使用し、包含とバイト制限を適用し、トラバーサルおよび再解析ポイントのパスを拒否します。
• 観察は、Window/Popup のジャーナリングを伴う、範囲を限定したサンプリング差分です。スコープ指定されたスナップショットを要求すると、 新しいスナップショットが生成され、他のデスクトップエージェントと同様に、古いノード参照が無効化されます。

.NET MAUI 機能に関する注意事項

• tree は scope: "logical" を使用する必要があります。ノード参照が識別するのは MAUI の IVisualTreeElement オブジェクトのみであり、 ネイティブハンドラーの PlatformView オブジェクトが返されることはありません。
• 型/名前/テキスト/スタイルクラスの検索、祖先、バインド可能プロパティ、リソース、縮退したスタイル、 スクリーンショット、プラットフォームアクション、パッケージ化されたアセット、および範囲を限定した監視は、 Windows と Android エミュレーターで実機検証済みです。
• プロパティの列挙は public static な BindableProperty フィールドを使用しており、設計上不完全です。 スカラー、enum、色、太さ、矩形、点の書き込みは、ターゲットの型が許容する範囲でサポートされます。 複雑なオブジェクトの書き込みは型付きエラーを返します。
• Windows の入力は OS レベルの生のインジェクションを使用し、raw を報告します。ルーティングされた入力は通知しません。 Android はタッチ、ホイール、キー、テキストをアクティビティ/ビュースタックを通じてディスパッチし、routed を報告します。 生の入力は決して通知しません。
• アクションパターンはノードとプラットフォームに依存します。public な ICommand スロットは 両プラットフォームで引き続き利用可能です。Windows は WinUI オートメーションプロバイダーをマップし、Android はアクセシビリティアクションをマップします。 Android は検証可能なノードローカルの事後条件を持つアクションのみを通知します。汎用の クリック/invoke および絶対パーセントの scroll は意図的に拒否されます。1 つのノードで 正確に受け入れられる動詞については props.patterns をお読みください。
• styles は意図的に縮退しています。MAUI のビジュアル状態はプロトコルの 疑似クラスではなく、スタイルフレームとして報告されます。疑似クラスの変更/検索およびネイティブツリースコープは unsupported-capability を返します。
• bindings は無効化されており、unsupported-capability を返します。MAUI はこのコントラクトに必要な アクティブなバインディング式とソースグラフを公開していません。
• failures は、同等の public なフレームワークの証拠が M38 で実装されるまで無効化されています。
• スクリーンショットは、Windows では WinUI レンダリングを使用し、Android では PixelCopy と通常ビューの Canvas フォールバック を使用します。ネイティブ/エアスペースのコンテンツおよび未アタッチのハンドラーにはプラットフォームの制限が残ります。
• MauiAsset 項目は、パッケージのマニフェストターゲットによって生成される不透明な maui-asset:/// 識別子を通じて 公開されます。assets が発行した識別子のみを開くことができます。
• 監視は範囲を限定した論理フィンガープリントとプラットフォームのライフサイクルジャーナルを使用します。スコープ付き スナップショットは新しい参照を発行します。オプションのピクセルハッシュは、プラットフォームのスクリーンショット制限に従います。
• Android は API 24+ をサポートします。スクリーンショットには API 26+ が必要です。iOS および Mac Catalyst はサポートされていません。

ネイティブダイアログとウィンドウ管理 (Windows、オプトイン)

ネイティブのファイルピッカーとメッセージボックスは別個の Win32 ウィンドウであり、tree からは見えず、 input からも到達できません。driver はその境界をカバーするために XamlMcp.Server 内で動作します。これは デフォルトで無効であり、Windows 専用です。MCP クライアントに登録されたコマンドで有効にします:

claude mcp add --scope user xamlmcp -- dnx [email protected] --enable-driver
codex mcp add xamlmcp -- dnx [email protected] --enable-driver

グローバルツールをインストールした場合は、dnx [email protected] を xamlmcp に置き換えてください。 Driver を有効にしたコマンドを登録する前に、既存の xamlmcp クライアントエントリを削除または更新してください。

手順は次のとおりです。ダイアログを開くボタンをクリックし (input/action)、次に dialog-wait がダイアログ参照とその構造 (ボタンのオートメーション ID、ファイル名編集が存在するかどうか — コントロールの値は決して含まない) を返し、その後 dialog-act がそれを意味的に操作します。 window-list/window-act はアプリ自身のトップレベルウィンドウを管理します (close には confirm: true が必要です)。

スコープと安全性:

• 一致するのはアタッチされたアプリのプロセスが所有するダイアログのみであり、さらに最後の変更呼び出し 以降に出現したものだけです — 既存のウィンドウには決して触れません。
• set-file-name のパスは --driver-file-roots <p1;p2;…> (デフォルト: ユーザー プロファイル) に対して検証されます。それ以外は型付きの path-not-allowed エラーになります。
• 昇格された (UAC) アプリおよび非対話型セッションはサポートされず、型付きエラーを報告します。
• ダイアログ参照はデタッチ、ダイアログのクローズ、またはアプリの終了時に古くなります — dialog-wait を再実行してください。

セキュリティモデル

• 明示的な診断のオプトイン — 各フレームワークのセクションには、呼び出し側が所有するビルドまたは起動の ゲートが示されています。アプリケーションがオプトインしない限り、何もリッスンしません。
• トークン優先のハンドシェイク。 すべてのエージェントトランスポートは、いかなる検査メソッドが ディスパッチされる前にも、起動ごとのトークンで認証を行う必要があります。認証されていない呼び出しは 型付きエラーを受け取り、接続は閉じられます。
• デスクトップの検出とパイプ。 Windows の名前付きパイプは PipeOptions.CurrentUserOnly を使用します。 検出ファイルは Unix では所有者のみが書き込み可能（ディレクトリは 0700、ファイルは 0600）で書き込まれ、正常な シャットダウン時に削除されます。サーバーは、PID が死亡しているか再利用されているエントリを削除します。
• Android のプライベート検出。 記述子はアプリプライベートのストレージに保持され、デバッグ可能な run-as を通じてのみサーバーが読み取ることができます。エージェントはデバイスのループバックにバインドし、 サーバーは自身が所有する正確な ADB フォワードを作成および削除します。トークン、プライベートパス、デバイス ポート、ホストポート、および生の ADB 出力は、MCP の結果やエラーに決して入りません。
• トークンとデスクトップのパイプ名は、MCP の出力やエラーメッセージに決して現れません。
• 認証されたセッションは同時に 1 つだけです。後から来たクライアントは、現在のセッションが終了するまで OS のレベルで待機します。

サンプル

samples/SampleApp は、.AttachXamlMcp() で接続された小さな Avalonia アプリで、すべてのツールが触れる対象を備えています。 メニューバーに加えて、選択、ツリー、トグル、テキスト、ピッカー、スクロール/仮想化の各コントロールを扱う タブ付きページがあり、これらはコントロール操作マトリックスのスイートがエンドツーエンドで駆動するものと 同じページです。これを実行して操作してみてください:

XAML_MCP=1 dotnet run --project samples/SampleApp

samples/MauiSampleApp は Windows/Android 向けの MAUI フィクスチャです。 エージェントのアタッチは Debug ビルドで有効になり、Windows ターゲットは非パッケージで実行されます:

dotnet run --project samples/MauiSampleApp -f net10.0-windows10.0.19041.0

インストールされている SDK ツールで Android ターゲットをビルドします:

dotnet build samples/MauiSampleApp/MauiSampleApp.csproj -f net10.0-android -c Debug

(PowerShell: $env:XAML_MCP="1"; dotnet run --project samples/SampleApp。)

samples/WpfSampleApp は WPF のプレイグラウンドです。その Debug ビルドは自動的にアタッチします:

dotnet run --project samples/WpfSampleApp

samples/WinUiSampleApp は、自己完結型の非パッケージ WinUI コントロール ラボです。検査、スタイルとリソース、サポートされるすべてのアクションパターン、観察ダイジェスト、スクリーンショット、 ポップアップおよびセカンダリウィンドウのルート、テキストおよびバイナリのアセット、そして Driver 用のネイティブ ファイルダイアログのために、安定した名前を公開します。エージェントのアタッチは #if DEBUG の内部に留まります。

dotnet run --project samples/WinUiSampleApp -c Debug -p:Platform=x64

無人での検査には、サンプルのオフスクリーン起動スイッチを渡します:

dotnet run --project samples/WinUiSampleApp -c Debug -p:Platform=x64 -- --hidden

その実プロセスでの MCP カバレッジを次で実行します:

dotnet test tests/XamlMcp.WinUI.Tests/XamlMcp.WinUI.Tests.csproj -c Debug --filter FullyQualifiedName~LiveWinUiSampleTests

インタラクティブな Driver ファクトは、ネイティブのデスクトップダイアログを開くためオプトインです:

$env:XAMLMCP_DESKTOP_TESTS = "1"
dotnet test tests/XamlMcp.WinUI.Tests/XamlMcp.WinUI.Tests.csproj -c Debug --filter FullyQualifiedName~WinUiDriverLiveTests

ガードされた生入力の証明も、実際のポインターを移動し、テストホストがフォアグラウンドの所有権を受け取る 必要があるため、デスクトップでのオプトインです:

$env:XAMLMCP_DESKTOP_TESTS = "1"
dotnet test tests/XamlMcp.WinUI.Tests/XamlMcp.WinUI.Tests.csproj -c Debug --filter FullyQualifiedName~LiveWinUiInputTests

デプロイ可能な非パッケージの出力を検証するには、Release を新しいディレクトリに発行します:

$publishDir = "artifacts/winui-sample/$([Guid]::NewGuid().ToString('N'))"
dotnet publish samples/WinUiSampleApp/WinUiSampleApp.csproj -c Release -r win-x64 `
  --self-contained true -p:Platform=x64 -p:WindowsPackageType=None -o $publishDir

出力には WinUiSampleApp.exe、WinUiSampleApp.pri、生成された .xbf ファイル、そして Assets/fixture.txt と Assets/fixture.bin の両方が含まれている必要があります。

ソースからのビルド

dotnet build                                 # XamlMcp.slnx
dotnet test                                  # suite on Avalonia 11.3.x
dotnet test -p:AvaloniaTestVersion=12.1.0    # same suite on the 12.x line

このソリューションには net10.0-android が含まれるため、完全な復元/ビルドには .NET Android ワークロードが必要です。デバイステストはオプトインのままです。エミュレータレーンには XAMLMCP_ANDROID_LIVE=1 を設定し、物理デバイスレーンにはさらに XAMLMCP_ANDROID_PHYSICAL=1 を 設定します。ADB が複数の認証済みデバイスを報告する場合は、XAMLMCP_ANDROID_DEVICE を設定します。

ライセンス

Apache-2.0 — LICENSE を参照してください。