MCPサーバー

Power Portals Pro MCPサーバー は、AIコーディングアシスタントにこのフレームワークの直接的な知識を提供し、構築中に体験できます。これはモデルコンテキストプロトコルサーバーであり、フレームワークに付属しており、ライセンスキーもサインアップもありません。

なぜ存在するのか

ドキュメントだけでは得られない2つの要素があり、どちらもコードの破損を引き起こします。

APIの表面は大きすぎて覚えていません。 両方のスタックに数百のコンポーネントがあり、それぞれに数十のパラメータがあります。パラメータ名を半分しか覚えていないエージェントは、コンパイルされない、あるいはコンパイルしても何もしない、もっともらしいものを書いてしまうのです。
あなたのDataverseはどのドキュメントにも含まれていません。 テーブルやカラムの論理名、リレーションシップスキーマ名、オプションセットの値、そして何よりも保存されたビューGUIDは、あなたの環境にのみ存在します。このサイトのすべてのコードサンプルは、他に書けるものがないため、省略記号としてビューIDを書き込んでいます。

答えは何でしょうか

フレームワーク — 両スタックのすべてのコンポーネントのパラメータおよびprop参照(型、デフォルト、許可値付き);このサイトから逐語的に採取した完全な作業サンプル;ガイド; AGENTS.mdの慣例;そしてBlazor-to-Reactパリティ行列。インストールしたパッケージとバージョンマッチングされています。
環境、読み取り専用 — 実際に持っているテーブルや列、各列がどのエディタにマッピングされているか、関係名、オプションセットの値、そして保存したビューとそれぞれの実際のGUIDです。

注記
すべてのDataverseツールはメタデータを読み取ります。レコードの読み取り、書き込み、削除は行わないので、エージェントを本番環境に向けることで、アクセスせずにデータの形状を学習できます。

プロジェクトへの追加

二つの場所で生きられる

ここには明確に言う価値のある鶏が先か卵が先かの問題があります。テンプレートは構成をプロジェクトに書き込みますが、サーバーが最も役立つのは、そのプロジェクトが存在する前、つまりテンプレートとそのオプションを選ぶときに使われます。ですので、自分用に一度インストールして、そこからはプロジェクトごとのファイルに任せましょう。

マシンごとに1回、どのフォルダでも

これにより、サーバーはどこでも利用可能になり、今まさにスキャフォールドしようとしている空のフォルダも含まれます。どのテンプレートを使うか、オプションの意味、設定内容を教えてくれます。意図的にピン留めを解除し、最新リリースを追跡しています:

Visual Studioはプロファイルフォルダからユーザーレベルの .mcp.json を読み取り、カーソルは ~/.cursor/mcp.jsonを使い、VS Codeの設定にはユーザーレベルのMCP設定があります。それぞれ同じ servers ブロックを使用します。

プロジェクトごとに、そのバージョンにピン留めされています

Power Portals Proテンプレートから作成されたプロジェクトはすでに配線されており、テンプレートはソリューションのルートに .mcp.json を書き込み、対応するサーバーバージョンにピン留めします。やることは何もありません。

既存のプロジェクトに追加するには、プロジェクトフォルダでこれを実行してください。同じ .mcp.json を自動で書き込んでくれます。

ただし、この方法が できない ことに注目してください:サーバーをピン留めせずに、フォルダはプロジェクト参照する PowerPortalsPro.* パッケージと一致するものではなく、最も新しい公開サーバーを受信します。これは現在のリリースを追跡するプロジェクトには正しいデフォルトであり、意図的に古いバージョンに保存されているプロジェクトでは間違ったデフォルトです。テンプレートのようにバージョンを付け加えてピン留めします。

あるいは、解決策のルートにファイルを自分で書くこともできます:

編集者が読むファイル
Visual Studio 2022 17.14+とVisual Studio 2026はソリューションフォルダから .mcp.json 読み取り、Claude Codeも同様です。VS Codeは .vscode/mcp.json を読み込み、カーソルは .cursor/mcp.json を読み込みます。どちらも同じ servers ブロックを使うので、コピーしてください。

dnx すでに持っている.NET 10 SDKが付属しています。すべてのPower Portals Proプロジェクトは ASP.NET Coreでホストされており、React SPAも含まれます。最初の実行でパッケージをダウンロードしキャッシュします。

両方を持つことが意図されたセットアップです。2つのエントリは同じサーバー名を使うため、両方のスコープを理解しているクライアントはプロジェクトのものを使い、プロジェクト内ではバージョンマッチした回答を得られ、他の場所では最新の回答が得られます。

もし欲しいなら、ppp-mcpコマンドです

このページのターミナルコマンド( login、 status、 logout など)は、何もインストールされていない状態で dnx を実行します: dnx PowerPortalsPro.Mcp login。 ppp-mcp loginを入力したい場合は、.NETグローバルツールとしてパッケージをインストールしてください。

それでPATHppp-mcpになります。.NET SDKは通常、Windowsでは%USERPROFILE%\.dotnet\tools、macOSやLinuxでは~/.dotnet/toolsのグローバルツールフォルダをそのフォルダに追加します。コマンドが見つからなければ新しいターミナルを開き、それでも見つからなければ、そのフォルダを自分でPATHに追加してください。

グローバルツールはインストールしたバージョンに留まり、 dnx が最新データを取得するので、以下のように更新してください。MCPクライアントはどちらの方法でも dnx を経由してサーバーを起動し続けられます。両者は同じフォルダのバインディングと保存したサインイン情報を読みます。

動作確認中

アシスタントにサーバーだけが答えられる質問をしてください。例えば「MainGridのすべてのパラメータをget_component_api表示してください」などです。ツールが利用できない場合は、クライアントが設定ファイルを取得していないことを意味します。ほとんどのツールは追加後に再起動が必要です。

更新

アップデート方法はインストール方法によります。

dnxでインストールし、ピン留め解除(上記のマシン全体のエントリ)は、実行不要です。dnxクライアントがサーバーを起動するたびにNuGetフィードから最新バージョンを解決し、次にクライアントを再起動したときに新しいリリースが届きます。
プロジェクトの .mcp.jsonにピン留めされています。 テンプレートは PowerPortalsPro.Mcp@<version>を書き、プロジェクトが使うフレームワークパッケージに合わせて作成します。パッケージをアップグレードする際にそのバージョンを変更し、回答が実際に実行されているフレームワークを説明し続けるようにしてください。

グローバルツールとしてインストール(dotnet tool install --global PowerPortalsPro.Mcp、PATHに上ppp-mcpします):

重要
まずMCPクライアントを閉じてください。実行中のサーバーは自分のファイルを開いたままにしており、パスへのアクセスが拒否されると更新が失敗します ...パスへのアクセスは拒否され 、何も使われていないまで続きます。その後、クライアントを再起動して新しいバージョンを読み込みます。

Dataverseへの接続

ドキュメントツールは設定が不要です。メタデータツールは環境への接続が必要で、 その接続はマシンではなくフォルダに属します。プロジェクト内で一度だけ実行してください:

環境はフォルダに属します

これにより、このフォルダは環境に割り当てられます。複数の顧客間で作業する場合、各プロジェクトはそれぞれの環境にサインインしたまま、異なるフォルダのエージェント同士が交差しません。これは pac auth select 唯一できないことです。単一のマシン全体のプロファイルを切り替えるため、顧客を一箇所で変更するとどこでも変わります。

サインインはデフォルトでデバイスコードの流れを使うので、SSH上でコンテナ内やWSLで動作し、電話で仕上げることも可能です。開きたい場合は --browser パスしてください。

1つのフォルダ内に複数の環境を

1つのフォルダは複数の環境に同時にサインインできます。例えば、顧客の開発、テスト、本番環境などです。別の環境を持つ各 login はフォルダのリストに追加し、 --name はその環境に以下の名前を付けます。

最初の環境が プライマリで、他のツールをリクエストしない限りすべてのツールはそれに反応します。 例えば「テスト中の接触時のビューをリストアップしてください」 と testから答え、次の質問はプライマリに戻ります。 --make-primary を login に渡して環境をプライマリに追加するか、アシスタントに並べ替えを依頼してください。

Dataverseに関わるすべての回答は、その環境の名前、位置、URLを明記することから始まり ます。したがって、本番環境の変更は開発中の変更と決して同じようには読み取れません。

物が保管されている場所

バインディングは フォルダ内に含まれ .ppp/mcp.json 。環境の名前とアカウントが順番にリストされ、秘密はなく、安全にコミットできます。リポジトリをクローンするチームメイトは、指示されなくても正しい環境を指し示します。
あなたのトークン はユーザープロファイルに保持され、オペレーティングシステムのキーストア(WindowsではDPAPI、macOSではKeychain、Linuxではlibsecret)によって暗号化されています。リポジトリには決して書き込まれません。キーストアがなければ、サインインはディスク上のリフレッシュトークンをクリアにする代わりに拒否します。

トークンキャッシュは環境ごとにキー化されているため、同じ顧客のリポジトリの2つ目のクローンは再度サインインを求めませんが、別の顧客からは常にサインインが求められます。また、フォルダに追加した各環境も同様にサインインを求められます。

コマンド

グローバルツールをインストールしていれば dnx PowerPortalsPro.Mcp <command>として、または ppp-mcp <command> として実行してください。これらはすべて、 --workspaceを通さない限り現在のフォルダ上で動作します。

login — サインインして、すでにバインドされた環境の後にこのフォルダにバインドします。オプション: --environment <url>、 --name <name>、 --make-primary、 --pac-profile <name>、 --username <upn>、 --tenant <id>、 --browser。すでにバインドされている環境を、再度サインインするように --environment test 設定しています。
status — このフォルダがどの環境を使っていて、どの環境がプライマリか、それぞれがどこから来たのか、どのアカウントがキャッシュされているのか、そして各接続が動作しているかどうかを判断します。
logout — このフォルダから環境を削除する:1つ --environment <name> 、 --all 1つずつ。保存したサインインも削除するために --forget を追加してください。
environments — ミラーリング可能なPower Platform CLIプロファイルを一覧にしてください。
azure — azure login、 status、 logout 、 subscriptions:このフォルダを展開ツール用のAzureサブスクリプションにバインドします。

その他の接続方法

環境と資格情報はこの順番で解決されるため、最も明確な意図表明が勝つ。

環境変数 — サーバーのenvブロック内のPPP_D365_URL、PPP_D365_CLIENT_ID、PPP_D365_CLIENT_SECRET。サービスプリンシパルと、これをCIや共有コンテナに配線する方法。PPP_D365_URLがフォルダーがバインドされているどの環境よりも先にプライマリ環境となり、サービスプリンシパルはプライマリのみに使用されます。
フォルダのサインイン — loginが書いた。通常の経路。
プロジェクト固有の設定、つまりポータル自体がユーザーの秘密やappsettingsから読み取るのと同じ、D365:Url、D365:ClientId、D365:ClientSecret(またはD365:Secret)。したがって、設定されたPower Portals Proプロジェクトはサインインが不要になることが多いです。

Power Platform CLIプロファイル

すでに環境を pacに保持している場合は、URLを探す代わりに一つの環境から始めることができます:

CLIにはアクセストークンを配布するコマンドがなく、認証情報は独自のストアに保管しているため、セッションを直接再利用することはできません。 --pac-profile は、環境とアカウントをプロファイルから取り出し、通常はプロンプトなしでサインインします。なぜなら、すでにセッションがあるからです。

注記
CLI自身のアクティブプロファイルは一切変更されません。 pac auth select は意図的に使われていません。すべてのプロジェクトを一度に移動させるためです。

ツール

ツールの名前を挙げる必要はほとんどなく、アシスタントが説明から選びますが、何があるかを知っておくと役立ちます。

ドキュメントは常に入手可能です

一度繋がった環境

環境の選択

Dataverseに到達するすべてのツールは、任意の environment ( testのような名前、 2のようなポジション、URLなど)を取得し、プライマリを使わずに使います。何も一致しない名前は、存在する環境のリストと拒否され、最も近い環境と照合されることはありません。

環境を追加するにはサインインが必要なので、 login だけがサインインできます。残りはアシスタントが頼んだときにできます。環境をポジション1に移動すると、後から書き込むたびにデフォルトで行われるようになり、 set_environment_index は最初にプライマリがいつ変わるか尋ね、 remove_environment 必ず尋ねます。

記録自体

メタデータは形状が何かを示します。これらは実際に何が入っているかを示します — どのオプションセットの値が実際にどの行を持っているか、ルックアップが入力されているか、コードが書いた行が正しいかどうかなどです。見られないエージェントは代わりに推測します。

読み方はサービス担当かサインイン済みユーザーであって、ポータルユーザーとしては読み取れません。ポータルのテーブル権限、列権限、行フィルターは一切適用されないため、環境内の内容が表示されるだけで、特定のポータルユーザーが何を表示するかは示されません。保存されたビューのFetchXMLは逐語的に実行されます。

新しいプロジェクトの立ち上げ

get_upgrade_plan はバージョン文字列を変更する前に呼び出すものです。このプロジェクトが参照するバージョンを読み取り、そのリリースとターゲットの間にあるリリースを特定し、移行命令とともにすべての変更点を返します。これは、他では何もキャッチできないバージョン名のファイル(サーバー .mcp.json ピンを含む)も含めて返します。このバージョンなしでパッケージを押し上げると、数年前のリリースに起因するビルドエラーが発生します。

マネージドソリューション

ポータルが動作する前にフレームワークはインストール PowerPortalsProCore 必要があり、ローカライズすれば PowerPortalsProLocalization します。これらはPower Platform CLIなしでリリースを取得し取り取り、インポートするため、到達する環境はこのフォルダが割り当てられている環境であり、 pac が指している環境ではありません。

インポートは長時間実行されるため、 install_solution 開始してジョブIDを返します。 get_solution_import_status 進捗と結果を報告し、失敗時にはDataverse独自のメッセージが表示されます。

注記
publish_customizations は「すべての カスタマイズをMaker Portalに公開 する」と同じ操作であり、環境上で保留中の すべての ものを公開します。自分の変更だけでなく、同僚の未完成の作業を公開できる共有開発環境に。 install_solution後には不要です。マネージドソリューションをインポートすると、その内容が公開されます。

あなた自身の解決策

サーバーが環境に加える変更—セキュリティロールの作成、付与または取り戻された特権—は、その環境に記録された独自のソリューションに入 .ppp/mcp.json。 create_solution 、パブリッシャーとソリューションは一度だけ、あなたが構築した環境でセットアップします。記録されるまでは、Dataverseをカスタマイズするツールは拒否します。なぜなら、ソリューション外で行った変更はデフォルトソリューションに取り残され、何もエクスポートできないからです。

また、バインディングはソリューションが管理 されていない 環境(作業中の環境の場合のデフォルト )か管理 されていないか(管理されている環境のみの環境の場合)かも記録します。 export_solution バージョンの最後の部分を上げてワークスペースにzipを保存し、 push_solution エクスポートして同じフォルダに割り当てられた別の環境(ビルドインデヴ、プッシュ・トゥ・テスト、本番環境)にインポートします。Power Portals Proのソリューションに依存している場合、ターゲット側がそのフォルダを持つまでインポートできません。

ポータルの役割

ポータルの役割は、半分はコード、半分はデータです。開発者は「Dealer」という名前が何を与えるかを決定し、管理者が誰がそれを保持するかを決めます。両者をつなぐのは文字列だけです。これらはDataverseの半分を、 AddPortalRole コールが書かれた場所と同じ場所から維持します。

文字列は全体の結合です。 登録とレコードの間に誤字があると、登録済みで割り当て可能で何も付与されない役割が生成されます — どこにもエラーがありません。登録を書いたエージェントにマッチするレコードを作成させることでそのギャップは埋められ、 check_setup すでに存在している不一致を検出します。プロジェクト内で書かれたすべてのロール名とレコードを比較し、欠落または非アクティブなものを報告します。

ポータル役割設定行は、どの新規登録ユーザーに役割を与えるかを決定します:全員、またはFetchXMLの条件に合致するユーザー。基準は、ポータルが不適切な基準で閉じられず、壊れたルールは正しく誰も一致しなかったルールとまったく同じように見えるため、行を書く前にポータルが適用するルールと照合されます。管理者はポータルの役割設定ページで同じ行を編集します。

注記
ロールを削除するとその割り当てはすべて捨てられ、誰が持っていたかも記憶されません。非アクティブ化しても何も得られず、クレームも発行されませんが、割り当ては保持されるため、役割を切り替える可逆的な方法となります。両方の削除ツールはまず確認を求めます。

ライセンス取得ウェブサイト

Power Portals Proのウェブサイトレコードは、特定のURLからポータルをライセンスするものです。これらは通常、環境ごとに1回、そしてポータルが本番ホストに移行した際に再度リストアップ、追加、維持されます。

すべてのエンドポイントが402を返すときに最初に確認すべきポイントです。 一致するアクティブレコードがなければ、そのホスト上の各データエンドポイントはリクエストを拒否します。レコードを削除すると次のリクエスト以降のライセンスも一緒に失われるため、調査中は無効化を優先します。削除は確認を求めます。

Azure deployment

これらのツールのほとんどは読み取りだけです。それらはサブスクリプションにReaderだけで十分で、何日もかかる疑問に答えます。 check_deployment が知っておくべきもので、プロジェクトに必要なものとApp Serviceが実際に持っているものを比較し、失敗を指摘します。これはユーザーシークレット、開発に残された環境、BlazorポータルのWebSocketsのオフ、デプロイされたホストをカバーしないPortal Websiteレコード、Dataverseにアクセスできないポータルにしか存在しない設定です。

7つのツールがApp Serviceを変更します: create_app_service、 configure_app_service、 set_app_service_settings、 deploy_to_app_service、 restart_app_service、 create_deployment_slot 、 swap_slots。それぞれが確認を求め、回答する前に費用がいくらかを教えてくれます。これはAzureの公開価格表から読まれた地域の実際の月額であり、小売リストはあなたが持っている企業契約や予約を無視していることに注記されています。新しいリソースは、後でスケールアップするのは1分で済むこと、過剰プロビジョニングは誰も再検討しないという見方から、常に温かく保てる最も安価な階層をデフォルトで選びます。

StandardまたはPremiumプランでは、ポータルにはそれぞれ独自のDataverse環境(UATに対する uat スロット、本番環境が本番環境に対して動作する)展開スロットを持つことができます。 create_deployment_slot それを作成し環境にリンクするため、UATで作業中にデプロイを要求すると、ビルドは本番ではなくUATスロットに送られます。環境名を付ける設定はスロットに留まるようにマークされており、 swap_slots はテスト済みビルドを本番環境に昇格させ、本番のデータに対して開始できます。スワップは、ある環境が別の環境に移行する場合、拒否されます。

注記
これらはAzure CLIを使わず、サインイン状態を読み取ったり変更したりしません。フォルダ内で ppp-mcp azure login 実行してください。Dataverseのバインディングと同様に、サブスクリプションはそのフォルダにのみ属しているため、複数のプロジェクトが異なる顧客を同時にターゲットにできます。 az account show これらのツールが何をするのかは何も教えてくれません。

Entra アプリの登録

ポータルが必要とする2つの登録と、それに続くジョブ。これらのステップがほとんどのセットアップを停滞させます。2つの別々の登録で、サインインアプリはテンプレートがランダム化したポートを含む返信URLが必要で、クライアントの秘密が1年後に失効すると、Entraの記載が一切ないエラーでポータルが停止します。

ツール自体は権限を持ちません。 すべての通話は、あなたがサインインしたアカウントの委任トークンで送信され、秘密を持たないパブリッククライアントに発行されます。つまり、ポータルで手動で実行できたのに、必要なディレクトリロールを403で拒否されるのです。アプリケーション開発者以上のアカウントでサインインすれば、これらは動作します。他の誰かとしてサインインすれば、害を及ぼすことはありません。API権限は請求されず、管理者の同意も付与されません。どちらの登録も許可を必要としません。

どちらも単独では動作しないため、両方の半分です。 アプリの登録にはトークンが割り当てられます。Dataverse のアプリケーションユーザーが そのトークンの機能を決定します。トークンのない登録は完全に認証されますが、その後すべての呼び出しで拒否されます。これは接続の破損と判断され、オブジェクトが欠落していると認識されます。そしてセキュリティ役割を持たないアプリケーションユーザーが作成され、目に見え、問題なく見え、何もできません。 create_dataverse_application_user は後半を同じステップで役割を割り当てます。これはサーバーが自分の3つのテーブルの外に書き込みを行う唯一の場所であり、アプリケーションユーザーは顧客データではなくインフラストラクチャであるため、どのツールもビジネスレコードを作成、変更、削除しません。

既存の登録に対して処理します。 各 create_*_registration ツールは clientIdを受け入れ、そのうちのツールではその登録を採用します。つまり、秘密を追加し、新しい返信URLを統合し、求めた場所に認証情報を書き込みます。確認には「既存の 登録に追加 する」と書かれており、作成ではなく、ある操作を承認して別の操作を得ることはなくなっています。既存の登録を変更するツール、 add_app_registration_redirect_uri や add_app_registration_secretもクライアントIDを優先します。表示名は一意ではなく、「Portal」と呼ばれる3つの登録を持つテナントは普通です。

作成されたクライアントシークレットはデフォルトで返されません。 Graphの応答から直接プロジェクトのユーザーシークレット、App Serviceアプリケーション設定、またはその両方に送られ、ツールはその場所と期限を報告し、過去の情報ではなく報告します。シークレットがサーバーが書き込めない場所(同僚のマシン、CIのシークレットストア、別のサブスクリプションのボールト)に届く必要がある場合、 destination: "return" を求め、その値が表示されてコピーします。確認は同意する前にそう示され、その結果に警告が付きます。シークレットはトランスクリプトに含まれているので、そのトランスクリプトが保存されていれば露出済みとみなし、疑わしい場合はローテーションしてください。秘密はデフォルトで 24ヶ月 間発行されます。これはEntraの ポータル が提供する最長の期間です。なぜなら、このフレームワークが実際に失敗しているのは盗まれた秘密ではなく、失效した秘密だからです。誰も記録していない日付でポータルが起動を停止し、Entraについて一切言及しないエラーが出ます。その上限はAPIではなくポータルのUIに付与されるため、 expiryMonths は5年に一度ローテーションする方が期限切れのリスクを冒すなら、最大120年(10年)までのものを受け入れます。これはデフォルトではありません。なぜなら、管理者が手作業で作成できない認証情報を見つけるのは驚きのものだからです。確認はあなたが何年申請したかを伝え、ポータルがそれを生成できなかったことを示します。

アプリはシークレットではなく証明書でサインインできます。add_app_registration_certificate Key Vaultで証明書を作成し、その秘密鍵は決してエクスポートできず、その公開部分を登録に追加します。そのアプリに環境をバインドし、ppp-mcp login --environment <url> --client-id <id> --certificate <url>を保有している人の各サインインにVaultが署名し、どのマシンにも秘密が残りません。ローテーションするには同じツールを再度実行します。remove_app_registration_certificate何も使わなかった時点で古い証明書を廃止します。

注記
意図的に欠落しているのは2つあります。 登録を削除する と、テナント内のすべてのアプリケーションのサインインが無効になり、30日間以内にしか回復できません。 管理者の同意を付与 することは、狭い委任行為を常設のテナント全体の権限に変える操作です。どちらもポータルを稼働させるために必要ないため、どちらも提供されません。新しいクライアントIDのDataverse アプリケーションユーザー を作成するのも別のステップで、ツール出力からコマンドが出されます。

期限切れの秘密を取り除くこと

クライアントシークレットとは、誰も書き留めていない日付に動かなくなるデプロイ済みポータルの一部です。これらはそれを削除したり、残ったものを再展開せずにローテーションできる場所に移動させたりします。

D365__ManagedIdentityIdをIDのクライアントIDに設定し、Azureポータルが最初に表示するオブジェクトやプリンシパルIDではなく、そのクライアントIDに独自のDataverseアプリケーションユーザー(他のものと同じように)create_dataverse_application_userを与えます。そうすればポータルは秘密なしで接続されます。

メール送信者

ポータルは、Dataverseのキューまたは有効ユーザーに解決しなければならないアドレスから確認およびパスワードリセットメールを送信します。 create_email_queue キューを作成し、メールボックスを承認し、Test & Enableを実行し、その結果を報告します。 check_email_sender 送信者が配達しない理由を説明します。返信なしアドレスの送信者としては、人のメールボックスではなくキューが正しい送信者です。

重要
あなたのためにできない2つのこと。アドレスにはExchange Onlineの共有メールボックスが必要で、ライセンス不要で、承認できるのはOffice 365のグローバル管理者かExchange管理者だけです。どちらかが欠けている場合、ツールはどちらかを指定し、修正後に再度実行すれば作業は完了します。Test & Enableが通るまでは、Dataverseはポータルのメールを受け取り、何も届けません。これはポータル側の成功と区別がつかないため、ツールはクリーンな結果を報告するのではなくテストを行います。

他言語での活動

サーバーが返す知識は英語であり、それは意図的なものです。アシスタントがそれを読むのです—ツールの応答を直接見ることはありません—だからアシスタントはあなたの代わりに翻訳します。あなたの言語で尋ねれば、あなたの言語で答えます。ただし、翻訳してはいけないのはコードです。コンポーネント名、パラメータ名、列名はすべてのプロジェクトで英語であり、会話がどの言語であれ、参照英語を維持することが、存在しない翻訳パラメータ名をアシスタントが発明するのを防ぐのです。

注記
何か、つまり “MainGrid Ansichten konfigurieren” の名前がついた質問は、コンポーネント名がどこでも同じなので、どの言語でも使えます。ツールはアシスタントに英語で検索するように指示しているので、名前が出ていない質問も使えます。

トラブルシューティング

「No Dataverse environment is bound to this project folder」 — そのフォルダで login を実行してください。自分がいると思うフォルダにいるか確認してください: status 解決したワークスペースのルートを印刷します。
「保存されたサインインはもはや有効ではありません」 とは、リフレッシュトークンが期限切れまたは取り消されたか、テナントが新しいやり取りを必要としている場合です。再度 login を実行してください。
「オペレーティングシステムのキーストアは利用できません」 というのは、libsecretデーモンがないヘッドレスLinuxボックスでよくあることです。代わりに PPP_D365_* 環境変数を通じてサービスプリンシパルを使いましょう。
サインインしているのに環境が接続を拒否します — アカウントは認証済みですが、その環境にアクセスできません。URLを確認するか、別のユーザーとして --usernameでサインインしてください。