How to Add Web Search to Flowise Agents With the You.com MCP Server

TLDR: To add web search to a Flowise agent, add a Custom MCP tool to the Agent node with a config that points at https://api.you.com/mcp and reads your key from a Flowise variable, then refresh Available Actions and enable you-search. Remote URLs work out of the box, while stdio commands are refused unless the server operator allows them. Pin two headers in the config to keep results small.

Flowise is a visual builder for AI agents and LLM apps, and its agents get tools from a prebuilt list, from Custom Tool JavaScript functions, or from MCP servers. This guide covers the MCP route in detail, then a Custom Tool alternative that trims results before the model reads them. Along the way it covers where the key should live, which actions to enable, and what Flowise does with a config it dislikes. For the host-agnostic server setup, see the You.com MCP server guide. Facts come from the Flowise docs and its source code at release 3.1.4, the You.com MCP docs, and live calls to the keyless profile on October 5, 2026.

What Search Tools Does Flowise Ship With?

The Flowise tools list includes wrappers for Brave Search, Exa, Google Custom Search, SearXNG, SerpApi, Serper, and Tavily, and the docs list no You.com node. One caution on that list: Google says the Custom Search JSON API is closed to new customers, and existing customers have until January 1, 2027 to move, so that wrapper is no starting point for a new project.

For a provider Flowise does not ship, the docs offer two routes. Apart from the prebuilt MCP tools, the docs call Custom MCP the most powerful feature, because it connects to any MCP server. Custom Tool is a JavaScript function you write. Because You.com runs a hosted MCP server, MCP is the shorter path, and it keeps tool definitions on the server side.

How Do You Add the You.com MCP Server to a Flowise Agent?

Step one: create a variable for the key. Flowise variables are Static or Runtime. A Static variable is saved with the value you type and retrieved as is. A Runtime variable fetches its value from the server's environment with process.env, using the variable's name. Name it YDC_API_KEY and prefer Runtime: set YDC_API_KEY in Flowise's environment, and the key lives in the server environment instead of the Flowise database. Either way, an exported flow holds only the variable reference. The docs also say API callers can override a variable's value per request, but only after you switch that on under Settings, Configuration, Security. Leave it off for a key variable. Get the key from the You.com platform.

Step two: add a Custom MCP tool. Create an Agent node, add a Custom MCP tool, and paste this config. The docs say to reference a variable with double curly braces and a $vars prefix:

{
  "url": "https://api.you.com/mcp",
  "headers": {
    "Authorization": "Bearer {{$vars.YDC_API_KEY}}"
  }
}

Step three: enable the actions. Refresh Available Actions. Flowise lists each tool the server exposes by name in capitals, such as YOU-SEARCH. The bare endpoint exposes four tools: you-search, you-contents, you-balance, and you-discover. Flowise passes the agent only the actions you tick, so enable you-search, add you-contents if the agent should read pages, and leave the other two off.

Flowise also checks tool metadata before the agent sees it. Names are limited to letters, digits, underscores, and hyphens, and descriptions are cut at 1,024 characters by default, with a log warning for text that reads like an instruction aimed at the model. The you-search description is 659 characters, and both You.com tools passed these checks unchanged.

To test the wiring first, use the keyless profile. It needs no header, exposes you-search and you-discover, and allows 100 queries a day:

{
  "url": "https://api.you.com/mcp?profile=free"
}

Streamable HTTP or Stdio: Which Does Flowise Allow?

For a config with a URL, Flowise connects with Streamable HTTP and falls back to SSE if that fails. The You.com server speaks Streamable HTTP, so it connects on the first try, and the docs call Streamable HTTP the recommended route because nothing is installed locally and server updates apply automatically.

Stdio is stricter than the docs suggest. The docs say to use it only when Flowise runs locally. In the source, a config with a command is checked against an operator allow-list, CUSTOM_MCP_ALLOWED_COMMANDS, that is empty by default, and the stdio protocol has to be switched on with CUSTOM_MCP_PROTOCOL=stdio. Running that check on an npx config returned Command 'npx' is not allowed. Permitted: (none). A URL config passes the same check untouched, which is one more reason to use the hosted endpoint.

One cost of the MCP route is visible in the source: Flowise opens a fresh MCP client for every tool call and closes it afterward. The You.com endpoint issues no session ID, so every search repeats the handshake before the call itself. A Custom Tool makes one request per search.

How Do You Keep Search Results From Flooding the Agent?

The you-search tool defaults to highlights and up to 30 results per section. Flowise hands the agent whatever the server returns: its MCP wrapper serializes the tool's whole content array into one JSON string. The You.com server lets the host pin search parameters with X-Search-* headers, and a pinned value wins over what the model sends, so the config is the place to set them:

{
  "url": "https://api.you.com/mcp",
  "headers": {
    "Authorization": "Bearer {{$vars.YDC_API_KEY}}",
    "X-Search-Count": "5",
    "X-Search-Extraction": "none"
  }
}

Pinned headers	Web results	Tool text	After Flowise's JSON string
X-Search-Count: 5	5	34,770 characters	37,115 characters
X-Search-Count: 5 and X-Search-Extraction: none	5	9,270 characters	9,487 characters

Same query, keyless profile, October 5, 2026. Sizes vary with the query and the pages behind it, so measure your own. Extraction none returns snippets without page highlights, which suits an agent only when it can open a page on demand through you-contents on the keyed endpoint. The JSON string adds a few percent of escaping on top, so the savings come from the headers, not from Flowise.

Search results are untrusted text. Flowise's Agentflow docs say agents can be configured to request permission before executing tools, and the Agent node shows a Require Human Input flag for each selected tool. Consider approval when the same agent can also write data or call other tools.

When Is a Custom Tool the Better Route?

Use a Custom Tool when you want to shape what the model reads, because MCP returns the server's full payload. The function below calls the REST endpoint, takes the key from the same variable, and returns five results as numbered lines. Create the tool with the name youcom_search, a description that says what it is for, such as "Search the live web for current information", and an input schema with one required string property named query.

const fetch = require('node-fetch');

const response = await fetch('https://ydc-index.io/v1/search', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': $vars.YDC_API_KEY
  },
  body: JSON.stringify({ query: $query, count: 5 })
});

if (!response.ok) {
  return 'Search failed with status ' + response.status;
}

const data = await response.json();
const web = (data.results && data.results.web) || [];

return (
  web
    .map((r, i) => {
      const snippet = (r.snippets && r.snippets[0]) || r.description || '';
      return (i + 1) + '. ' + r.title + '\n' + r.url + '\n' + snippet;
    })
    .join('\n\n') || 'No results.'
);

The function follows the Custom Tool docs: it imports node-fetch, uses the schema property as $query, reads the variable as $vars.YDC_API_KEY, and returns a string. The REST endpoint returns snippets by default, so the function reads the first snippet and falls back to the description. The Web Search API reference lists the other request parameters, and the agent tool calling guide covers tool schemas for other frameworks. Choose MCP when you want the provider's tool definitions and updates, and a Custom Tool when you want control over arguments and output.

A Custom Tool also runs on a Tool node in Agentflow, which executes exactly the tool you picked with no model choosing for you. Because nothing fills in the arguments there, the docs say the Tool Input Arguments must be defined and filled explicitly, so map query to the field that holds the user's question. Use a Tool node when every run should search, and an Agent node when the model should decide.

What Fails, and How Do You Spot It?

Available Actions shows "No Available Actions". That is the fallback Flowise returns when listing tools throws, with the description "No available actions, please check your API key and refresh". The causes are a config that does not parse or that Flowise's security check refuses, a connection problem, or a request with no usable Authorization header. On the keyed endpoint, both a missing header and an empty bearer token get a 401, and an empty token is exactly what a Runtime variable produces when its environment variable is unset.

The list fills in but every search fails. A wrong key does not stop the list. In testing, an invalid token passed initialize and tools/list on the keyed endpoint, and listing actions is only a tools/list call. The failure arrives when the agent searches, as a tool error reading "Error: Failed to perform search. Error code: 401". A misspelled variable name behaves the same way, because Flowise leaves an unknown reference as literal text and the header goes out as Bearer {{$vars.YDC_API_KYE}}. Run one real search from the agent, or test the key with the cURL guide, before you trust the setup.

A 405 in the logs. When the first connection fails, Flowise logs "Error connecting to MCP server" and retries over SSE, which opens a GET that this endpoint answers with 405. Read the earlier line for the real cause.

The agent never calls the tool. Check that the action is ticked in Available Actions, that the tool is on the Agent node, and that the chat model supports tool calling, because Flowise's Tool Agent docs describe an agent that uses function calling to pick tools and arguments. A specific tool description helps the model decide when to search.

Example verification: Flowise's own validator, variable substitution, tool sanitizers, and variable resolver were run from its GitHub source under Node, and they accepted the three configs above, refused the npx config, and left the You.com tools unchanged. The Custom Tool function was run against an offline mock of the REST endpoint, covering the request shape, a 401, and an empty result. The sizes in the table were measured live on the keyless profile, and the keyed endpoint's response to missing, empty, and invalid tokens was tested with deliberately invalid values, never a working key. No Flowise instance was run and no successful keyed call was made, so canvas steps follow the docs and the keyed MCP path follows the source.

Related Guides

• How to Set Up the You.com MCP Server for Web Search in Any Client
• How to Add Web Search to Agent Tool Calling With the You.com Web Search API
• How to Call the You.com Web Search API With cURL
• What Is the You.com Web Search API? Endpoint, Pricing, and Limits
• How to Add Web Search to Cursor With the You.com MCP Server