tidewave-integration

Tidewave MCP 統合

MCP を介して Phoenix アプリの実行時情報を取得します。利用できる場合は、Bash より Tidewave ツールを優先してください。

絶対に守ること — 例外なし

1. 開発環境のみ — 本番環境では Tidewave ツールを絶対に使用しないでください。本番データのコピーがある共有開発サーバーも避けてください
2. BASH より TIDEWAVE を優先 — mcp__tidewave__get_docs > web_fetch、execute_sql_query > psql
3. 最初に利用可能か確認 — 対応する mcp__tidewave__* ツールがある場合にのみ Tidewave を呼び出してください
4. SQL は読み取り中心 — SELECT には execute_sql_query を使用し、データ変更には注意してください
5. 正確なバージョンを確認 — get_docs は最新ではなく、使用中の mix.lock のバージョンに対応したドキュメントを返します

クイックリファレンス

タスク	Tidewave ツール	フォールバック
ドキュメントを取得	mcp__tidewave__get_docs Module.func/3	web_fetch hexdocs.pm/...
コードを実行	mcp__tidewave__project_eval	mix run -e "code"
SQL クエリ	mcp__tidewave__execute_sql_query	psql $DATABASE_URL
ソースを検索	mcp__tidewave__get_source_location	grep -rn "defmodule"
DOM を調査	mcp__Tidewave-Web__browser_eval	ブラウザーで手動確認
スキーマを一覧表示	mcp__tidewave__get_ecto_schemas	lib/*/schemas/ を読む
ログを読む	mcp__tidewave__get_logs level: :error	tail -f log/dev.log

検出

# Check endpoint
curl -s http://localhost:4000/tidewave/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"ping"}'

または Claude Code で /mcp を使用すると、接続済みのサーバーを確認できます。

基本パターン

関数をすぐにテスト

# mcp__tidewave__project_eval
MyApp.Accounts.create_user(%{email: "[email protected]"})

マイグレーションを検証

-- mcp__tidewave__execute_sql_query
SELECT column_name, data_type FROM information_schema.columns
WHERE table_name = 'users';

LiveView をデバッグ（ブラウザーから PID を取得）

# mcp__tidewave__project_eval
pid = pid("0.1234.0")
:sys.get_state(pid) |> Map.get(:socket) |> Map.get(:assigns) |> Map.keys()

セットアップ要件

# mix.exs
{:tidewave, "~> 0.6", only: :dev}

# endpoint.ex (in dev block)
plug Tidewave

# config/dev.exs (for LiveView source mapping)
config :phoenix_live_view,
  debug_heex_annotations: true,
  debug_attributes: true

依存関係とエンドポイントのプラグによって Tidewave のストリーム可能な HTTP サーバーが公開されますが、MCP クライアントへの登録は行われません。現在のランタイムを http://localhost:<port>/tidewave/mcp に別途設定し、このスキルに依存する前に Tidewave ツールが利用可能であることを確認してください。

信頼性を確保するためのガード

ワークツリー／ポートの確認（複数ワークツリー構成では最初に実行）：ワークツリーが複数ある場合、ポートの異なる開発サーバーも複数起動しています。Tidewave の結果を信頼する前に、エンドポイントがこのチェックアウトに属していることを確認してください。config/dev.exs を grep して設定済みのポートを調べ、project_eval File.cwd!() で検証します。異なるワークツリーのパスが返された場合は、誤ったサーバーをデバッグしています。

SQL の前にスキーマを調査：カラム名を推測しないでください。このセッション中にまだ調査していないテーブルに対して SQL を作成する前に、get_ecto_schemas（または information_schema.columns へのクエリ）を実行してください。推測したカラム名によるエラーは、スキーマの調査よりも大きなコストになります。

出力サイズの制限：ランタイムの出力サイズに上限はありません。必ず制限してください。SQL では LIMIT 20、eval では Enum.take(20)、大きな構造体には inspect(x, limit: 50, printable_limit: 500) を使用します。大量に出力するのではなく、対象を絞って再クエリしてください。

browser_eval のフォールバック：mcp__Tidewave-Web__browser_eval がない場合やエラーになる場合でも、処理を止めずにサーバー側で同じ状態を調べてください。project_eval で :sys.get_state(pid) を使って LiveView の assigns を確認する、Phoenix.LiveViewTest でレンダリング済み HTML を確認する、またはテンプレートのソースを直接読む方法があります。

QA ウォークスルーのパターン：機能の完成後、project_eval／browser_eval を使って短いチェックリストを実行します。レコードの作成、取得、主要イベントの実行、get_logs level: :error にエラーがないことの確認を行ってください。「スモークテストに合格した」だけではなく、各ステップの合否を報告してください。

積極的なランタイム確認

Tidewave を問題が発生したときだけ使わないでください。ワークフローのチェックポイントで、ランタイムの状態を自動的に確認します。

• コード編集後：get_logs level: :error（ランタイムのクラッシュを検出）
• 機能の完成後：project_eval によるスモークテスト（動作を確認）
• 計画の前：get_ecto_schemas とルートの eval（具体的なコンテキストを確認）
• 調査時：ユーザーに尋ねる前にエラーを自動取得
• LiveView の UI バグ：コンポーネントを編集する前に browser_eval で DOM の状態を確認

統合ポイントの全容については ${CLAUDE_SKILL_DIR}/references/proactive-patterns.md を参照してください。

参考資料

詳しいパターンについては、以下を参照してください。

• ${CLAUDE_SKILL_DIR}/references/proactive-patterns.md - ワークフローのチェックポイントにおけるプッシュ型ランタイムパターン
• ${CLAUDE_SKILL_DIR}/references/tool-examples.md - ツールの使用例一式
• ${CLAUDE_SKILL_DIR}/references/validation-checklist.md - ランタイムの検証パターン