Runtime intelligence for Phoenix apps via MCP. Prefer Tidewave tools over Bash when available.
\nmcp__tidewave__get_docs > web_fetch, execute_sql_query > psqlmcp__tidewave__* tools are presentexecute_sql_query for SELECT, be careful with mutationsget_docs returns docs for YOUR mix.lock versions, not latest| Task | \nTidewave Tool | \nFallback | \n
|---|---|---|
| Get docs | \nmcp__tidewave__get_docs Module.func/3 | \nweb_fetch hexdocs.pm/... | \n
| Run code | \nmcp__tidewave__project_eval | \nmix run -e \"code\" | \n
| SQL query | \nmcp__tidewave__execute_sql_query | \npsql $DATABASE_URL | \n
| Find source | \nmcp__tidewave__get_source_location | \ngrep -rn \"defmodule\" | \n
| Inspect DOM | \nmcp__Tidewave-Web__browser_eval | \nManual browser inspection | \n
| List schemas | \nmcp__tidewave__get_ecto_schemas | \nRead lib/*/schemas/ | \n
| Read logs | \nmcp__tidewave__get_logs level: :error | \ntail -f log/dev.log | \n
# Check endpoint\ncurl -s http://localhost:4000/tidewave/mcp \\\n -H \"Content-Type: application/json\" \\\n -d '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"ping\"}'\nOr use /mcp in Claude Code to see connected servers.
# mcp__tidewave__project_eval\nMyApp.Accounts.create_user(%{email: \"test@example.com\"})\n-- mcp__tidewave__execute_sql_query\nSELECT column_name, data_type FROM information_schema.columns\nWHERE table_name = 'users';\n# mcp__tidewave__project_eval\npid = pid(\"0.1234.0\")\n:sys.get_state(pid) |> Map.get(:socket) |> Map.get(:assigns) |> Map.keys()\n# mix.exs\n{:tidewave, \"~> 0.6\", only: :dev}\n\n# endpoint.ex (in dev block)\nplug Tidewave\n\n# config/dev.exs (for LiveView source mapping)\nconfig :phoenix_live_view,\n debug_heex_annotations: true,\n debug_attributes: true\nThe dependency and endpoint plug expose Tidewave's streamable HTTP server; they\ndo not register it with an MCP client. Configure the current runtime separately\nwith http://localhost:<port>/tidewave/mcp, then verify that Tidewave tools are\navailable before relying on this skill.
Worktree/port check (FIRST, in multi-worktree setups): multiple\nworktrees = multiple dev servers on different ports. Before trusting any\nTidewave result, confirm the endpoint belongs to THIS checkout: grep\nconfig/dev.exs for the configured port, and verify with\nproject_eval File.cwd!() — if it returns a different worktree path,\nyou're debugging the wrong server.
Schema introspection BEFORE SQL: never guess column names. Run\nget_ecto_schemas (or query information_schema.columns) before writing\nSQL against a table you haven't already introspected this session. A\nguessed-column error costs more than the introspection.
Output-size guard: runtime output is unbounded. Always cap it —\nLIMIT 20 in SQL, Enum.take(20) in evals, inspect(x, limit: 50, printable_limit: 500) for large structs. Re-query narrower rather than\ndumping wide.
browser_eval fallback: if mcp__Tidewave-Web__browser_eval is absent\nor errors, don't stall — inspect the same state server-side: LiveView\nassigns via :sys.get_state(pid) in project_eval, rendered HTML via\nPhoenix.LiveViewTest, or read the template source directly.
QA walkthrough pattern: after a feature completes, run a short\nchecklist through project_eval/browser_eval: create the record, fetch\nit back, exercise the main event, check get_logs level: :error is clean.\nReport each step's pass/fail — not just \"smoke test passed\".
Query runtime state at workflow checkpoints without waiting\nto be asked:
\nget_logs level: :error (catch runtime crashes)project_eval smoke test (behavioral check)get_ecto_schemas + routes eval (concrete context)browser_eval to inspect DOM state before editing componentsSee ${CLAUDE_SKILL_DIR}/references/proactive-patterns.md for full integration points.
For detailed patterns, see:
\n${CLAUDE_SKILL_DIR}/references/proactive-patterns.md - Push-like runtime patterns at workflow checkpoints${CLAUDE_SKILL_DIR}/references/tool-examples.md - Complete tool usage examples${CLAUDE_SKILL_DIR}/references/validation-checklist.md - Runtime validation patterns