tavily-search-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@tavily-search-mcpsearch for latest AI breakthroughs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Tavily Search MCP
A cost-aware stdio MCP server for the official Tavily Search API.
Tool
tavily_search supports:
Basic, Fast, and Ultra Fast Search at 1 API credit.
Advanced Search at 2 API credits, only when explicitly selected.
General, news, and finance topics.
Domain and date filters.
Up to 20 ranked results with source URLs and relevance scores.
Reported credit usage, response time, and request ID.
The server always sends auto_parameters: false, include_usage: true, and excludes generated answers, raw pages, and images. This keeps cost and response size predictable while leaving synthesis to the MCP client.
Related MCP server: tavily-pool-mcp
Configuration
Required at call time:
TAVILY_API_KEYOn Windows, run npm run setup for the first-install configuration window. Enter multiple API keys separated by semicolons. It saves the API URL as a non-secret setting and stores the key array as a current-user DPAPI ciphertext under %APPDATA%\tavily-search-mcp\api-key.dpapi. Environment variables (TAVILY_API_KEYS or TAVILY_API_KEY) still take precedence for CI or temporary sessions.
Requests rotate across configured keys. Authentication, rate-limit, and quota responses (401, 429, 432, 433) can switch to the next distinct key, with a hard maximum of three attempts per MCP call. Server failures and ambiguous errors are not retried.
Optional:
TAVILY_API_URL=https://api.tavily.com/searchThe server starts and lists tools without a key, then fails closed with a clear error if a search is attempted before TAVILY_API_KEY is configured. Secrets are never accepted as tool arguments or printed.
Each installation must use its own Tavily credentials. Do not share .env files, DPAPI ciphertext, setup screenshots, or API keys with other users.
Development
npm install
npm run checkCodex configuration
After building, register the compiled entry point and forward only the required environment variable:
[mcp_servers.tavily_search]
command = "node"
args = ["D:/path/to/tavily-search-mcp/dist/index.js"]
env_vars = ["TAVILY_API_KEYS", "TAVILY_API_KEY", "TAVILY_API_URL"]
startup_timeout_sec = 20
tool_timeout_sec = 60No request is retried automatically. HTTP redirects are rejected so the API key cannot be forwarded to another origin.
Available Tools
1 tooltavily_searchTavily SearchARead-only
Search the public web with Tavily. Defaults to Basic Search (1 API credit). Advanced Search costs 2 credits and must be explicitly selected. Automatic parameter selection is disabled to prevent an unexpected upgrade to Advanced.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Focused web search query | |
| topic | No | general | |
| end_date | No | YYYY-MM-DD; cannot be combined with time_range | |
| start_date | No | YYYY-MM-DD; cannot be combined with time_range | |
| time_range | No | ||
| exact_match | No | Require quoted phrases in the query to match exactly | |
| max_results | No | ||
| search_depth | No | basic/fast/ultra-fast cost 1 credit; advanced costs 2 credits | basic |
| exclude_domains | No | Domains to exclude, without schemes or paths | |
| include_domains | No | Domains to include, without schemes or paths |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| credits | No | |
| keySlot | No | |
| results | Yes | |
| keyCount | No | |
| requestId | No | |
| responseTime | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context about the credit cost structure and the disabling of automatic parameter selection, which goes beyond annotation data and clarifies a potential gotcha.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose cleanly, the second covers cost and selection behavior. No redundant phrases, and the most important caveat is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with an output schema and annotations, the description effectively communicates the key non-obvious aspect (credit cost and advanced selection). Other details like date constraints are left to the schema, which already provides them. The description is sufficient for an agent to understand and safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 70%, so most parameters are already documented. The description adds nuance to the search_depth parameter by stating that Advanced costs 2 credits and must be explicitly selected, and that automatic upgrades are disabled. This is more contextual than the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the public web with Tavily' with a specific verb (search) and resource (public web). It also distinguishes between Basic and Advanced search modes, providing scope. Since there are no sibling tools, no differentiation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on the default search mode (Basic), the cost difference, and that Advanced must be manually selected. It also warns that automatic parameter selection is disabled, which helps the agent avoid unexpected credit usage. No alternative tools are listed, so context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
tavily_search
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The single tool has a clear and unique purpose.
The tool name 'tavily_search' follows a consistent verb_noun pattern. With only one tool, naming consistency is trivially maintained.
The server has a single tool, which feels thin for a typical MCP server. It is borderline appropriate for a narrowly focused search server, but could benefit from additional related tools.
The tool covers the core web search capability well, including basic and advanced search options. However, it lacks other potentially useful Tavily features like extract or crawl endpoints, making it slightly incomplete for a full Tavily integration.
Maintenance
Related MCP Connectors
MCP server for Google search results via SERP API
Official SerpApi MCP server for Google, Bing, and other search engines.
Serper MCP — wraps the Serper Google Search API (serper.dev)
Related MCP Servers
- FlicenseAqualityDmaintenanceTavily MCP Server implementation that uses fastmcp and supports both sse and stdio transports. It also supports more up to date functionalities of Tavily.41-
- AlicenseBqualityDmaintenanceA local MCP server that exposes Tavily search as a tool and rotates across multiple API keys for reliability.1MIT
- FlicenseBqualityDmaintenanceMCP server using Tavily API for web search, enabling web search queries via stdio transport.5-
- FlicenseBqualityDmaintenanceMCP server that provides web search functionality using the Tavily API. It runs in stdio transport mode and can be integrated with Cursor or other MCP clients.3-