インストール
npx -y @modelcontextprotocol/server-puppeteer誰向けか
モデルにローカルの実ブラウザでウェブページを開かせ、コンソールを見せ、またはスクリーンショットを残させたい人向け。証拠は次を述べる：これは Puppeteer によるブラウザ自動化の MCP サーバーであり、モデルはページと対話し、スクリーンショットを撮り、実ブラウザ環境で JavaScript を実行できる。
あなたのマシン上で動くため、ローカルファイルとローカル/内部 IP にも届く。このプライバシー境界を受け入れ、機微データを管理できる場合に限り接続すべきである。証拠はクライアント名を列挙せず、対象は「MCP を設定できるクライアントをすでに持ち、npx を実行できる人」までである。
公式ページは servers-archived ツリーにある。証拠は保守状態や代替実装を別に書いていないため、今も更新されている現行製品だと思わないこと。
3 分で最初の試行を完了する
証拠が示す NPX 経路を使う。クライアントの MCP 設定で次を使う：
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-puppeteer"]
同時に Docker を主経路にしない。証拠が補足するのは、Docker はヘッドレス Chromium を使い、NPX はブラウザウィンドウを開くことだけである。
前提条件：このマシンに Node/npx がある。最初はアクセス権があり、フォーム送信もログインもしない公開ページだけを開く。起動後はこのマシンでブラウザが動き、ローカルファイルと内部アドレスに触れる可能性がある。
設定場所：クライアントの MCP サーバー設定（stdio のコマンドと引数）。保存後にクライアントを再起動または再読み込みする。
低リスクな最初の呼び出し：証拠が完全に書き出した puppeteer_navigate だけを呼び、直前に述べた URL へナビゲートする。証拠はそのツールのパラメータ欄を示さない。collect 要約は screenshot、click、hover、fill、select、evaluate にも触れるが、対応 locator は展開されていない。最初はそれらを呼ばない。
成功シグナル：NPX 経路ではこのマシンのブラウザウィンドウが開き、指定したアドレスに留まるはずである。その後リソース console://logs（テキストのコンソール出力）または screenshot://<name>（PNG）を読める。ウィンドウが出なければ、先に NPX であって Docker ではないことを確認する。
使用例
事例 1：モデルに指定した公開ページを開かせる。puppeteer_navigate を呼ぶ。証拠が保証するのは「ブラウザで任意の URL にナビゲートする」ことだけ。タイムアウト、リダイレクト、このマシンの cookie を付けるかは書いていない。確認できるのは、ナビゲートがローカルの実ブラウザで起きることである。隔離されたクラウドセッションだと思わないこと。
事例 2：ページを開いたあとコンソールを確認するかスクリーンショットを残す。最初の証拠はスクリーンショットと JavaScript 実行が可能だと述べ、リソース証拠は console://logs（ブラウザの全コンソールメッセージ）と screenshot://<name>（撮影済みスクリーンショットの PNG）を示す。証拠はスクリーンショットツール名、<name> の生成方法、evaluate のパラメータを書いていない。したがって二回目はこれらのリソースを読むだけにするか、「証拠はスクリーンショット/JS 実行だけを保証する」層で止め、セレクタやスクリプトを捏造しない。
利用上の境界
ローカルブラウザはローカルファイルとローカル/内部 IP にアクセスでき、機微データを持ち出せる。NPX は可視ウィンドウを開き、Docker はヘッドレス Chromium である。挙動が違うので混ぜたあとウィンドウを成功シグナルにしない。証拠が完全に名指しするツールは puppeteer_navigate だけ。対話系能力（クリック、入力）にはパラメータ付き locator がなく、実行するとページ副作用がある。リソースはコンソールとスクリーンショットだけ。取り消し、cookie 掃除、ブラウザ終了の手順はない。証拠はクライアント一覧、権限モデル、アーカイブ後の代替パッケージを書いていない。