Flowise web search tutorial / 2026

How to Add Web Search to Flowise with MCP in 2026

Flowise can discover tools from a remote MCP server inside an Agent node. This guide keeps the tool surface deliberate: search finds a short list of sources, while the Flowise prompt decides when the model should search and how it should cite the results.

20264 min readFor agent builders

Quick answer

Connect a Custom MCP tool to your Flowise Agent node.

In an Agent node, add a Custom MCP tool, choose Streamable HTTP, enter the Webstractor endpoint, refresh Available Actions, and enable search_web. The agent can then discover public sources without a custom JavaScript tool.

MCP configuration

{
  "type": "streamable-http",
  "url": "https://webstractor.com/mcp"
}

Before you begin

What you need

A current Flowise installation with an Agent node
A configured tool-calling chat model
Outbound HTTPS access from the Flowise server
No local MCP process or browser automation is required

Step-by-step setup

Connect Webstractor to Flowise

Open the agent’s Custom MCP setup

Edit the Agent node, open its tools list, and add Custom MCP. Flowise documents Streamable HTTP as the remote-server option; it only needs the endpoint for Webstractor.

Register the hosted endpoint

Name the connection webstractor, select Streamable HTTP, and use this configuration. Leave headers empty unless your account documentation explicitly gives you a service credential.

Flowise Custom MCP

{
  "type": "streamable-http",
  "url": "https://webstractor.com/mcp"
}

Limit the available actions

Refresh Available Actions and select search_web for this chatflow. A smaller tool set makes the model’s choice clearer. Add extract_public_url later only when the flow also needs full-page reading.

Give the agent a source policy

Tell the Agent node when to search, how many sources to request, and to preserve URLs. This prompt distinguishes discovery snippets from evidence.

Agent instruction

instructions: |
  Search the public web when the question needs information not present in the conversation.
  Use search_web with 5 results unless the user requests another limit.
  Return the source URL beside every factual summary.
  Treat snippets as leads, not complete evidence.

Validation

Test tool selection in the Flowise chat

Open the chatflow preview and ask for several public sources on a specific topic. Inspect the execution trace: the Agent should call search_web once, then answer from the returned result list.

Also test a timeless question already answerable from the conversation. The agent should not search reflexively. That check catches prompts that turn every message into an unnecessary tool call.

Expected tool: search_web
Expected arguments: a concise query and bounded limit
Expected answer: source links remain visible

Flow design

Separate discovery from page reading

For a research flow, expose both search_web and extract_public_url but describe their roles explicitly. Search should produce candidates; extraction should read only the few pages needed for the answer.

This two-stage pattern is easier to inspect than asking the agent to search repeatedly. It also leaves the canonical URL attached to the evidence that reaches later Flowise nodes.

Troubleshooting

When Available Actions stays empty

First confirm that the Flowise host can reach the HTTPS endpoint. Then verify that the transport is Streamable HTTP and that the URL ends in /mcp. Save the tool and refresh the actions again.

If actions appear but the model never calls them, use a model with tool-calling support and make the Agent instruction explicit. If it calls search repeatedly, add a one-search-per-question rule and a stopping condition.

Available data

What you can extract

Ordered public search results
Titles, source URLs, and concise snippets
Language, country, result-limit, and site controls
Markdown for model reading or schema-v1 JSON for downstream nodes

AI workflows

Where normalized data helps

Research chatflows with visible sources
Documentation discovery restricted to one hostname
Lead-in discovery for a separate extraction step
Current public-source lookup without maintaining a search tool

Boundaries

Public data only

Search results are discovery metadata; read a selected source before making detailed claims.
The Flowise server must be able to make outbound HTTPS requests to webstractor.com.
Private pages, login sessions, pagination, and personalized results are not available.

webstractor.com does not bypass CAPTCHAs, login walls, paywalls, access controls, or regional restrictions. Review the source’s terms and applicable law before collecting or reusing data.

Common questions

Flowise and Webstractor FAQ

Does Flowise need a local Webstractor package?

No. Flowise connects directly to the hosted Streamable HTTP endpoint.

Should I enable every Webstractor action?

Only enable the actions the flow needs. search_web is enough for discovery; add extraction or vertical search tools for deliberate use cases.

Can the Flowise agent search one website?

Yes. Instruct it to pass the site argument when discovery must stay on one hostname.

Ready to try it?

Turn a public URL into useful context.

Connect Webstractor MCP Read the Webstractor MCP guide