Web search

Models have training cutoffs; your problems don't. The agent's web_search tool lets it look things up on the live web mid-task — no browser tab, no copy-paste, and no separate search API key to configure.

When the agent reaches for it

The tool is described to the model as the way to get up-to-date information — so the agent typically searches when a question outruns what it can know from training or from your project:

• Current versions — "what's the latest stable release of Next.js?" before pinning a dependency.
• Documentation — API shapes, config options, or flags for a library it's about to use.
• Error messages — pasting an unfamiliar build error and asking for a fix often triggers a search for the exact message.

You can also just ask it to search ("look up how X changed in v3") and it will.

What you see in the transcript

A search shows up like any other tool call — a tool card with the query, a running indicator, and expandable results once it completes. The results are a readable list: each hit's title, URL, and snippet. The agent then reasons over those snippets in its answer, and when the answer draws on them it ends with a short Sources list of the URLs it actually used, as links.

Because web_search is read-only, it never raises an approval card — searches run freely, like file reads.

How it works underneath

The search request goes through Mel's backend, which asks a search provider (Tavily) and returns the formatted results to the agent. Practical consequences:

• No key, no setup — search works out of the box on every install, with your own model key too.
• A daily allowance per plan — searches run on Mel's search account, so each plan has a daily number of searches; the Free plan's is small. See Billing & usage.
• Snippets, then pages — a search returns titles, URLs and summaries. When the agent needs a page's actual content, its web_fetch tool reads that one page.

Web pages are data, never instructions

What the agent reads from the web reaches the model labelled as data, under one rule that data is never an instruction — so a page that says "ignore the user" is summarised, not obeyed.

Working well with search

• Include the error text or version constraint in your prompt — concrete strings make for precise queries.
• If you want the agent to *avoid* the web (offline work, or to keep it grounded in your repo alone), say so; it only searches when it decides fresh information is needed.
• Search pairs naturally with agentic work: "find the current recommended config for this tool, then update our setup to match" runs a search, then edits files with the usual diff cards and approvals.