Tavily MCP setup: web search and page extraction
Set up Tavily MCP locally with JSON and an API key. Test search and extraction separately, verify original sources and isolate connection failures.
Research often involves two tasks: finding a useful page and reading the relevant information on it. Plan two separate checks. Start with a public topic for which you know an original source and define the passage you want to retrieve. If a response is empty, this makes it possible to tell whether the search failed to find a useful address or the subsequent page reading failed.
Plan search and extraction separately
Tavily documents the tavily-search and tavily-extract tools. For the local setup shown here, the repository uses tavily-mcp@latest with TAVILY_API_KEY. The provider also documents a remote MCP endpoint. This guide covers local startup. Compare provenance in the Tavily search and the web data directory.
| Task | Your input | Observed result |
|---|---|---|
| Search | One precise query | Suitable original URL found |
| Extraction | One selected public URL | Requested passage present |
| Comparison | Same page in a browser | Content and context agree |
Configure local access
The example suits clients with a mcpServers JSON root. Replace the placeholder in your local file while preserving existing entries. For another format, use the client overview and converter. Submit only sanitized examples without actual credentials to public checking tools. The essential startup condition is that the executable is available in the environment of the client running it.
{
"mcpServers": {
"tavily": {
"command": "npx",
"args": [
"-y",
"tavily-mcp@latest"
],
"env": {
"TAVILY_API_KEY": "YOUR_TAVILY_API_KEY"
}
}
}
}
The @latest suffix follows the published repository example and does not pin a release. Record the version actually used after testing. A repeatable handover needs both that package release and the client version. Successful startup alone does not establish that search works: a completed tool request provides the next observation about whether the configured access reaches the service from your environment.
Find a source, then read it
After connecting, read the tool list and current input schemas. Record which search and extraction tools are actually available.
Run a bounded search for your public test question. Select a suitable original source from the returned addresses.
Submit that single address to the extraction tool. Check whether it includes the passage you identified beforehand.
Open the same URL in your browser and compare the heading, passage and publication context. Explicitly record anything missing.
A returned title or short summary does not establish the content of the entire page. Record the specific passage supporting your statement. If the page has changed, preserve both retrieval times in your notes. Repeat the same question for a comparison before adding filters or additional pages. That separates a change in your procedure from a change to the source itself, and makes the result easier for another person to inspect.
Distinguish empty results from connection failures
A missing tool list points first to the connection or startup path. If a tool list exists but a request fails, read the actual service error. Check credentials and usage allowance in your provider account. For empty extraction, open the exact returned URL in a browser: a redirect, sign-in requirement or dynamically loaded view may require another checking method. Empty extracted text does not prove the statement is absent from the website.
Use the troubleshooting navigator to isolate the technical step. The Brave guide and research comparison help you choose another route. When you only need to read a known URL, start with one retrieval rather than an open search. This keeps the next attempt bounded and makes it clearer which condition changed.
- Must search and extraction always be used together?
- No. If you already know the address, you can plan the reading check directly with that URL.
- Does empty extraction mean the search found nothing?
- No. Search and page retrieval are separate steps. Identify which one failed to produce a useful response.
- Is the local setup entirely offline?
- No. The local MCP process uses the external Tavily service. Take that into account when choosing test queries.
- Can I repeat the same test later?
- Record the package version, inputs and time. Search results and page content can change even if your setup stays the same.
Provider sources checked on 1 October 2026. The test plans are editorial suggestions.
- Tavily: MCP documentation
Show retrieval command
curl -s https://docs.tavily.com/documentation/mcp - Tavily: repository and local setup
Show retrieval command
curl -s https://github.com/tavily-ai/tavily-mcp