Flutter MCPサーバー（Dart MCP Server）とは？24ツールの内訳と既定オフの落とし穴【2026年8月時点】

AIエージェントに「このFlutterアプリのエラーを直して、ホットリロードまでやっておいて」と頼めるようにするのが、GoogleのDart／Flutterチームが配布しているDart MCP Serverです。エディタ拡張ではなく、解析サーバー・pub・Dart Tooling Daemon・VMサービスといったローカルの開発ツール群をMCPのツールとしてエージェントへ差し出す常駐プロセスとして動きます。この記事では、pub.dev版1.1.1が公開する24個のツールの内訳、そのうち10個が既定で無効なままである点、実行中アプリへつなぐための前提条件、UI自動操作を任せたときに発生する副作用を、日付つきの一次情報で整理したものです。MCPという規格そのものの仕組みはMCPとは何か、AIと外部ツールをつなぐ標準規格の解説にまとめてあります。

まとめ：設定は数行で終わり、つまずくのは既定オフのツールとDTD接続

先に結論を示します。Dart MCP Serverの導入そのものは、MCPクライアントの設定ファイルにcommandとargsを書く数行で終わります。2026年8月19日時点の最新はpub.devのdart_mcp_server 1.1.1（2026年8月7日公開）で、READMEには「WIP. This package is still experimental」と実験段階である旨が明記されたままです。

実務でつまずく箇所は3つに集約されます。1つ目は、公開されている24ツールのうち10個が既定で無効になっていること。テスト実行のrun_testsやアプリ起動のlaunch_appが該当し、起動引数に--enableを足さない限りエージェントからは見えません。2つ目は、ホットリロードや実行時エラー取得がDart Tooling Daemon（DTD）への接続を前提としており、純Dartアプリでは--observe付きで起動しておく必要があること。3つ目は、UI操作を任せるflutter_driver_commandを働かせると実機のキーボード入力が効かなくなる副作用です。

採用の線引きとしては、コード解析・依存関係の整理・ホットリロードの往復までは任せてよい範囲です。テスト実行とアプリのライフサイクル操作は、有効化するツールを名前で列挙してから渡してください。E2E自動操作は検証専用のビルド構成を分けることが前提になります。

Dart MCP Serverが担う役割と他社製MCPサーバーとの構造の違い

MCPサーバーと呼ばれるものの多くは、外部サービスのWeb APIをエージェント向けに包み直したものです。FigmaやGitHubのMCPサーバーがその典型で、通信先はクラウド側にあります。Dart MCP Serverはここが違い、通信先が開発者の手元にあるツールチェーンです。

解析サーバーとDTDを束ねてエージェントへ渡す仕組みの要点を整理

サーバー本体はstdio（標準入出力）をトランスポートとして動くDartプロセスで、内部でDart Analysis Server、pubコマンド、Dart Tooling Daemon、VMサービスに接続します。エージェント側から見ると、これらがすべてanalyze_filesやpubといった単一のツール名として並びます。MCPクライアント側の必須要件はToolsとResourcesへの対応で、Rootsに対応していると作業対象のディレクトリをサーバー側へ渡せるため体験が良くなる、という構成です。

解析サーバーを子プロセスとして抱える設計上、応答が止まったときの後始末も実装されています。1.0.2（2026年6月22日公開）では、SIGTERMに時間内で応答しない解析サーバーへSIGKILLを送る処理が入りました。

pub.devでの配布状況と実験段階という位置づけの判断基準

1.0.0（2026年5月28日公開）で、配布経路がDart SDK同梱からpub.devへ移りました。CHANGELOGにはdart mcp-serverコマンドがdart run dart_mcp_server@のエイリアスとして動き続ける旨が書かれています。設定ファイルの記述を変えずに済む配慮ですが、実体はpub.dev上のパッケージを解決して実行する形に変わっています。

2026年8月19日時点のpub.dev APIの値は、pub points 135／160、直近30日のダウンロード6,633、likes 1、ライセンスはBSD-3-Clause、発行元はtools.dart.devの検証済みパブリッシャーです。ダウンロード数に対してlikesが極端に少ないのは、SDK経由の呼び出しが主でパッケージページを踏む人が少ないためと読めます。依存しているプロトコル実装のdart_mcpは0.5.2（2026年6月29日公開）で、こちらもまだ0系です。

導入手順とクライアント別の設定、Dart SDKのバージョン条件

設定ファイルに書くのはcommandとargsの2項目だけで足りる

Gemini CLIやCursorのようにmcpServers形式の設定ファイルを持つクライアントでは、次の記述で起動します。

{
  "mcpServers": {
    "dart": {
      "command": "dart",
      "args": ["mcp-server"]
    }
  }
}

Claude Codeでは設定ファイルを直接編集せず、コマンドで登録できます。

claude mcp add --transport stdio dart -- dart mcp-server

VS CodeでGitHub Copilotから使う場合は、Dart拡張がVS Code側のMCP APIへサーバー定義を登録する仕組みになっており、ユーザー設定に"dart.mcpServer": trueを書くだけで済みます。必要な拡張の版は、公式ドキュメントがv3.116以降、パッケージのREADMEがv3.114以降と記載しており、2026年8月19日時点で両者は一致していません。手元の拡張が古い場合は更新してから試すのが安全です。

ドキュメントとpubspecで食い違うSDK要件をどう解釈するか

必要なSDK版の記述は2か所で食い違う状態です。公式ドキュメントとREADMEはDart 3.9系以降と書いていますが、pub.dev上の1.1.1のpubspecはsdk: ^3.12.0を宣言しています。つまり3.9系から3.11系のSDKでは1.1.1が解決されず、古い版へ落ちる形です。ドキュメントの記述はSDK同梱時代の名残と考えたほうが実態に合います。

Flutter 3.47系のSDKを入れていればDartは3.12系以降になるため、この制約は問題になりません。手元のSDKが古い場合の版上げ判断はFlutter 3.44のSPM既定化と移行判断を、SDK導入そのものはFlutterのSDK導入とflutter doctorによる診断手順を参照してください。

24あるツールの内訳と、既定で無効な10個を有効化する実務手順

READMEのツール表はtool/update_readme.dartが自動生成しており、各ツールのenabledByDefaultをそのまま出力しています。2026年8月19日時点で公開されているのは24ツール、うちEnabled列がYesなのは14ツールです。

既定で無効な10ツールには開発中に使いたいものが含まれる運用上の注意

既定で有効なのは、解析のanalyze_files、DTD操作のdtd、UI駆動のflutter_driver_command、実行時エラー取得のget_runtime_errors、hot_reloadとhot_restart、コード知能のlsp、pubとpub_dev_search、依存パッケージを読むread_package_urisとrip_grep_packages、roots、vm_service、widget_inspectorの14個です。残る10個は指定しない限り無効のままです。

この一覧で目を引くのはrun_testsです。ツール説明には「ALWAYS use instead of `dart test` or `flutter test` shell commands」と大文字で書かれているにもかかわらず、既定は無効という設定です。有効化しないままエージェントに任せると、シェル経由でflutter testを叩く挙動へ落ちます。テスト結果の構造化された読み取りを期待していたのに素のログが返ってくる、という食い違いはここから生まれます。

enableとdisableの指定は名前でもカテゴリでも書き分けられる

有効化と無効化は起動引数で指定します。--enableはツール名でもカテゴリ名でも受け付け、--disable（短縮形は-x、別名は--exclude-tool）も同様です。判定は、名前による無効化、名前による有効化、カテゴリによる無効化、カテゴリによる有効化の順に見て、どれにも当たらなければ各ツールの既定値へ落ちます。名前指定がカテゴリ指定より強い、と覚えておけば足ります。

dart mcp-server --enable run_tests --enable flutter_app_lifecycle -x create_project

カテゴリは analysis、cli、dart_tooling_daemon、flutter、flutter_app_lifecycle、flutter_driver、package_deps の7種です。アプリの起動・停止・一覧・ログ取得はまとめて flutter_app_lifecycle に属するため、上の例のようにカテゴリ名ひとつで5ツールが同時に立ち上がります。

なお、公式ドキュメントがCodex CLIの登録例で案内している--force-roots-fallbackは、実装側では既に隠しフラグ扱いで、ヘルプにも「Deprecated: tools to manage roots are always available」と書かれています。--toolsオプションも非推奨で、--enableと--disableへの置き換えが案内されています。ドキュメントの記述をそのまま貼るとすでに古い指定を渡すことになるため、手元ではdart mcp-server --helpで現行のフラグを確かめてから設定してください。

ホットリロードと実行時エラー取得を成立させるDTD接続の前提

Flutterは自動登録され、純Dartはobserve付き起動が要る

ホットリロード、ウィジェットツリーの読み取り、実行時エラーの取得は、いずれも実行中アプリへの接続が成立していなければ動きません。この接続はDart Tooling Daemonの探索を経由します。Flutterアプリはdebugモードとprofileモードで起動すればDTDへ自動登録されるため、追加の作業は不要です。ただし--no-ddsを渡した場合はDart Development Serviceごと止まり、DTDも起動しません。

純粋なDartアプリケーションでは自動登録が働かないため、--observeを付けて起動する必要があります。さらに--print-dtdを渡すとDTDのURIが標準出力に出るので、エージェントが候補を総当たりで探す手間が消えます。両フラグはスクリプト名より前に置く決まりになっている点に注意してください。

dart --observe --print-dtd bin/main.dart

READMEはこの取り決めをGEMINI.mdのようなRULESファイルへ書き、エージェントが常に参照できる状態にしておく運用を勧めています。プロジェクト直下に置いておけば、起動のたびに人が言い添える必要はなくなります。

vm_serviceメタツールでDTD経由以外の接続も張れるようになった

1.1.0（2026年7月23日公開）でvm_serviceというメタツールが追加され、VMサービスのURIを直接指定した接続と、VMサービスのメソッド呼び出しがまとめて扱えるようになりました。DTD経由で起動していないアプリに対してもホットリロードが通る道ができた形です。同じ版では「Harden various tools against compromised agents」として、乗っ取られたエージェントを想定した堅牢化も入っています。

続く1.1.1では、実行中アプリへ能動的に接続し、変更後はホットリロードするようエージェントを促す指示文とエラーメッセージの改善が行われました。hot_reloadの説明文に「利用者の指示を待たずに実行してよい安全な操作である」という趣旨の一文が入っているのはこの流れによるものです。

flutter_driver_commandでUI操作を任せる場合の準備と副作用

スクリーンショット取得、タップ、テキスト入力、スクロールをエージェントに任せる場合はflutter_driver_commandを使います。既定で有効なツールですが、対象アプリ側の準備がなければ何も動きません。

検証用の起動経路を本番ビルドから切り離しておく実務設計の段取り

まず依存関係にflutter_driverを足し、main()の中で拡張の有効化をコンパイル時定数でゲートします。

void main() {
  if (const bool.fromEnvironment('ENABLE_FLUTTER_DRIVER')) {
    enableFlutterDriverExtension();
  }
  runApp(const MyApp());
}

起動時はflutter run --dart-define=ENABLE_FLUTTER_DRIVER=trueのように定数を渡します。ゲートを外して常時有効にすると、実機での確認時に困ることになります。Flutter Driverの拡張を有効にすると実際のキーボード入力が無効化されるためです。手で文字を打って確かめたい場面ではenableTextEntryEmulation: falseを指定する回避策がありますが、その分エージェント側の入力操作が通らなくなるトレードオフを抱えます。

Web向けの検証にも制約があります。Webビルドではflutter_driver拡張が利用できないため、ブラウザを操作させたい場合は-d chromeではなく-d web-serverで起動する必要があります。

受託開発でDart MCP Serverを入れてよい場面と見送る場面

ここまでの事実を踏まえて、案件へ持ち込むかどうかの線を引きます。

採用してよいのは解析と依存整理を往復させる開発中の工程に限る理由

入れる価値がはっきりしているのは、実装中に解析エラーを潰しながらホットリロードで確認を繰り返す工程です。analyze_filesとlspで存在しないシンボルを書かせない歯止めが効き、pub_dev_searchでパッケージ選定の当たりを付けられ、hot_reloadで反映まで一気通貫になります。これらはいずれも既定で有効なので追加設定も要りません。エージェントが実在しないAPIを書く事故は、解析結果を読める状態にするだけで目に見えて減ります。

テスト実行を任せたい場合は--enable run_testsを明示し、アプリの起動と停止まで委ねるなら--enable flutter_app_lifecycleを足してください。既定のまま「テストも回して」と頼むのは、期待と実装がずれる典型的な設定漏れです。

顧客資産の読み取り範囲を説明できない案件では見送るべき契約上の理由

見送るべき条件は3つです。第1に、rip_grep_packagesとread_package_urisが依存パッケージのソースを横断的に読む前提のツールであるため、顧客から預かったコードの取り扱い範囲を契約で細かく定めている案件では、読み取り対象の説明が難しくなります。この2つを-xで外して使う判断も可能ですが、外すとエージェントの調査能力は目に見えて落ちます。

第2に、CIへ組み込む用途には向きません。stdioで人の操作を受けて動くローカル開発向けの設計であり、パイプラインでのテスト実行やビルド検証を置き換えるものではないためです。第3に、パッケージ自体がWIPかつ実験段階と明記されており、1.0.0の公開から2026年8月19日時点までのおよそ3か月弱で5版が出ています。ツールチェーンの版を契約で固定する必要がある案件では、この更新速度そのものが不確定要素になります。

導入判断そのものに迷う段階なら、フレームワークの選定から見直したほうが早い場面もあります。判断材料はFlutterの将来性をリリース実績と国内案件数から見た整理にまとめました。設計と実装を含めて任せたい場合はFlutter / React Nativeによるクロスプラットフォーム開発でご相談ください。

よくある質問

Dart MCP ServerとFlutter向けの非公式MCPサーバーはどう違いますか？

Dart MCP Serverは発行元がtools.dart.devの検証済みパブリッシャーで、Dart／Flutterチームが配布している実装です。ウィジェットインスペクタやDTDのように、SDK内部の仕組みへ直接つながる点が非公式実装との違いになります。ドキュメント検索に特化した非公式サーバーとは役割が重ならないため、併用しても構いません。

設定したのにツールが一覧に出てこないのはなぜですか？

まずrun_testsやlaunch_appのように既定で無効なツールでないかを確かめてください。該当する場合は--enableで名前かカテゴリを指定します。次にSDK版です。1.1.1はDart 3.12系以降を要求するため、それより古いSDKでは古い版が解決され、ツール構成も当時のものになります。

ホットリロードを頼んでも実行されないときは何を見ますか？

実行中アプリへの接続が張れているかを最初に確認します。dtdツールでDTDのURIを一覧し、接続済みアプリが見えているかを調べてください。純Dartアプリなら--observe付きで起動しているか、Flutterアプリなら--no-ddsを渡していないかが典型的な原因です。DTD経由で見つからない場合はvm_serviceでURIを直接指定する手もあります。

利用状況のデータが外部へ送信されることはありますか？

パッケージとして実行される場合、解析データの送信は環境変数DASH__TOOLが設定されているかどうかで決まります。CHANGELOG 1.0.0には、この変数が設定されていなければ計測は行わないと明記されています。エントリポイントの実装も、変数が読めなければ計測用オブジェクト自体を生成しない構造です。

Android Studioでも使えますか？

2026年8月19日時点で、READMEのAndroid Studio向け設定手順はコメントアウトされたままで、公式の案内は出ていません。stdioに対応するMCPクライアントであれば技術的には接続できますが、設定手順が示されているのはGemini CLI、Cursor、VS Code、Claude Code、Codex CLI、OpenCode、Antigravityです。

関連記事

• MCPとは？AIと外部ツールをつなぐ標準規格の仕組み・MCPサーバーの役割を解説：規格そのものの定義と全体像
• MCP Go SDKとは？導入に必要な環境構築と事前準備について徹底解説：MCPサーバーを自作する側の実装
• Flutterの環境構築｜Windows・macOS別のSDK導入とflutter doctor診断：SDK導入と診断の手順
• Flutter 3.44とは？SPM既定化とHCPPで変わる移行判断：SDK版上げの判断材料
• Flutterの将来性を数値で判断する｜リリース実績・国内案件数・競合の現在地：継続するかどうかの判断材料