Loomal

tavily-mcp MCP server in n8n web search inside your workflows.

n8n connects to MCP servers over HTTP, not stdio — so tavily-mcp (2.1k stars) needs a URL before the MCP Client Tool node can reach it. Here's the bridge setup and the node configuration.

n8n's AI Agent workflows consume MCP servers through the MCP Client Tool node, which speaks SSE or Streamable HTTP to a URL. tavily-mcp, like most npm-distributed servers, is a stdio process — it has no URL of its own. That mismatch is the one real piece of work in this setup: you either bridge the stdio server to HTTP yourself, or point n8n at a hosted remote endpoint.

Tavily documents a hosted remote MCP endpoint as of mid-2026 — check their docs for the current URL and auth scheme. This guide shows the self-hosted route, which works on any n8n instance that can run Node processes nearby.

Expose tavily-mcp over HTTP

Run the stdio server behind a stdio-to-HTTP bridge such as supergateway on a machine your n8n instance can reach (for self-hosted n8n, the same host or Docker network works). The bridge spawns tavily-mcp as a child process and serves it as an SSE endpoint:

terminal
export TAVILY_API_KEY=tvly-YOUR_API_KEY
npx -y supergateway \
  --stdio "npx -y tavily-mcp" \
  --port 8808
# SSE endpoint: http://localhost:8808/sse

Configure the MCP Client Tool node

In your workflow, add an AI Agent node if you don't have one, then attach an MCP Client Tool node as one of its tools. Set the endpoint URL to the bridge address (http://localhost:8808/sse from the example — use the container or host name instead of localhost if n8n runs in Docker), choose the matching transport (SSE here), and leave authentication off unless you put the bridge behind one.

Once the node connects, n8n discovers the server's tools automatically. You can expose all of them to the agent or whitelist specific ones in the node's options — for a search server, exposing everything is normal.

Run a test execution

Wire a Chat Trigger to the AI Agent and run the workflow with a prompt that forces a lookup — "what did Tavily announce most recently?" is a fitting test. In the execution log you should see the agent call out to the MCP Client Tool and get search results back. If the agent answers without calling the tool, tighten the system prompt to tell it a live web search tool is available.

Troubleshooting the n8n side

Connection refused on the node: n8n can't reach the bridge URL. In Docker, localhost inside the n8n container is not the host — use host.docker.internal or a shared network alias. Confirm the bridge is still running; npx processes die with the terminal that started them unless you run them under a process manager.

Tools discovered but searches fail: that's the Tavily API key, which lives in the bridge's environment, not in n8n. Re-export TAVILY_API_KEY and restart the bridge. Also note that community MCP nodes differ from the built-in MCP Client Tool — if your n8n version predates the built-in node, upgrade rather than mixing community variants. There is no config file to edit and no restart of n8n itself required; everything is workflow-level.

Listing and alternatives

tavily-mcp's live listing sits on the Loomal marketplace at https://loomal.ai/marketplace/tavily-mcp, including its probed tool list. Because n8n consumes remote MCP endpoints natively, it pairs naturally with Loomal's index of hosted, x402-ready servers — endpoints a workflow's agent can call and pay per request in USDC, no bridge process to babysit.

FAQ

Can n8n run tavily-mcp directly with npx?

No. n8n's MCP Client Tool node only speaks SSE or Streamable HTTP to a URL. A stdio server like tavily-mcp needs a bridge such as supergateway in front of it, or you can use a hosted remote MCP endpoint — Tavily documents one; check their docs for current details.

Where do I put my Tavily API key in n8n?

You don't put it in n8n at all for the self-hosted route — the key is an environment variable (TAVILY_API_KEY) of the bridged tavily-mcp process. n8n only needs the bridge's URL. If you use a hosted endpoint with header auth, the node's credential settings carry it instead.

Why does the MCP Client Tool node say connection refused?

The bridge URL isn't reachable from where n8n runs. In Docker, swap localhost for host.docker.internal or a compose network alias, and verify the supergateway process is still alive — it stops when its terminal closes.

The agent never calls the search tool — is the setup broken?

Not necessarily. If tools were discovered (visible in the node), the connection is fine; the model just chose not to search. Mention in the agent's system prompt that it has live web search and should use it for current-events questions.

More MCP servers for n8n.

Loomal lists remote-ready servers your workflows can connect to over HTTP.

Browse the marketplace