tavily-firecrawl-mcp
This server provides web search and web page content extraction capabilities for AI assistants, powered by Tavily and Firecrawl APIs.
web_fetch: Extracts a web page's content as Markdown (default) or plain text. Uses Tavily Extract as the primary provider, with automatic fallback to Firecrawl Scrape if Tavily fails (due to auth errors, rate limits, 5xx errors, network issues, or empty results). Key options include:query— reranks/reorders content relevanceformat—markdownortextextract_depth—basicoradvancedonly_main_content— strips navigation, ads, and footers (Firecrawl)timeout— configurable request timeoutReturns metadata including which provider was used and whether fallback occurred.
web_search: Performs web searches via Tavily Search, returning titles, URLs, and content snippets. No fallback provider — requires a Tavily API key. Key options include:max_results— 1–20 resultssearch_depth—basicoradvancedtopic—generalornewsinclude_answer— optionally returns a synthesized answer
Flexible configuration: API keys (
TAVILY_API_KEY,FIRECRAWL_API_KEY) are set via environment variables; unconfigured providers are skipped, enabling Tavily-only or Firecrawl-only modes.Proxy support: Set
WEB_FETCH_PROXYto route outbound API requests through a proxy.
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-firecrawl-mcpsearch for recent developments in quantum computing"
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-firecrawl-mcp
一个用于网页抓取和搜索的 MCP(Model Context Protocol)服务器。
web_fetch—— 把网页正文提取为 Markdown(或纯文本)。以 Tavily Extract 为主用,失败或返回空时自动回退到 Firecrawl Scrape。web_search—— 用 Tavily Search 搜索网页(返回标题、URL、摘要,可选合成答案)。无备用。
API key 从环境变量读取。未配置 key 的 provider 会被直接跳过,不会向它发起任何请求。
适用场景
抓取单个网页的正文内容(博客、文档、新闻等)。
当主用服务(Tavily)不可用时,自动用备用服务(Firecrawl)兜底,提高可用性。
用 Tavily 做联网搜索,获取最新信息。
Related MCP server: OneSearch MCP Server
环境要求
Python ≥ 3.11
Tavily API key(
TAVILY_API_KEY)可选:Firecrawl API key(
FIRECRAWL_API_KEY),用于抓取回退。不配则web_fetch仅用 Tavily。
运行方式
本服务用 Python 实现,推荐用 uvx(uv 的命令运行器)运行 —— 无需全局安装、自动隔离环境。
方式一:uvx(推荐)
无需 pip install,直接运行。两种来源:
# 已发布到 PyPI 时
uvx tavily-firecrawl-mcp
# 或者直接从 git 仓库运行
uvx --from "git+https://github.com/bpx/tavily-firecrawl-mcp" tavily-firecrawl-mcpuvx 会根据
pyproject.toml的[project.scripts]入口点(tavily-firecrawl-mcp = tavily_firecrawl_mcp.server:main)找到并运行服务。首次运行会自动创建隔离环境并安装依赖。
方式二:本地 pip 安装
在本目录下:
pip install -e .然后即可通过命令 tavily-firecrawl-mcp 或 python -m tavily_firecrawl_mcp 启动。
调试 / 检查
用官方 MCP Inspector 可视化调试:
npx @modelcontextprotocol/inspector uvx tavily-firecrawl-mcp配置 API key
在环境(或 MCP 客户端加载的 .env)中设置:
export TAVILY_API_KEY=tvly-xxxxxxxxxxxx
export FIRECRAWL_API_KEY=fc-xxxxxxxxxxxx # 可选仓库内附 .env.example。
出站代理(可选)
当 Tavily / Firecrawl 的 API 端点在你的网络下无法直连或不稳定(例如国内网络),可通过 WEB_FETCH_PROXY 指定本地代理:
export WEB_FETCH_PROXY=http://127.0.0.1:7890设置 WEB_FETCH_PROXY 后它优先级最高,并禁用 httpx 的环境变量回退;未设置时,httpx 仍会读取标准的 HTTP_PROXY / HTTPS_PROXY / ALL_PROXY 环境变量。
工具
web_fetch(url, ...)
参数 | 类型 | 默认值 | 说明 |
|
| 必填 | 要抓取的页面 URL。 |
|
|
| Tavily 会按该意图对提取内容重排。 |
|
|
| 输出格式。 |
|
|
| Tavily 提取深度。 |
|
|
| 仅 Firecrawl 生效 —— 去掉导航/广告/页脚。 |
|
|
| 单次请求超时,单位秒。 |
返回 { ok, url, provider, content, format, used_fallback, failed_providers, metadata }。
当结果由 Firecrawl 在 Tavily 失败后产出时,used_fallback 为 true。
web_search(query, ...)
参数 | 类型 | 默认值 | 说明 |
|
| 必填 | 搜索词。 |
|
|
| 结果数量(1–20)。 |
|
|
| advanced 更慢但更深入。 |
|
|
| 切换为新闻搜索。 |
|
|
| 是否同时返回合成答案。 |
返回 { ok, query, answer, results: [{title, url, content, score}] }。
回退机制说明
web_fetch 按顺序遍历 provider 链:Tavily → Firecrawl。
若 Tavily 已配置且返回非空内容 → 直接返回。
若 Tavily 因可重试错误失败(auth、限流、5xx、网络、空内容)且 Firecrawl 已配置 → 尝试 Firecrawl,标记
used_fallback: true,并把 Tavily 的失败记录写入failed_providers。不可重试错误(如 404)会立即抛出,不尝试备用。
所有 provider 都失败或都未配置时,工具返回
ok: false及结构化的failures列表,便于调用方处理。
未配置 key 的 provider 不会出现在链中,因此只配一个 key 即可实现 Tavily-only 或 Firecrawl-only。
客户端配置
ZCode(~/.zcode/mcp.json 或项目内 .zcode/mcp.json)
注意:ZCode 的配置文件格式与 Claude Desktop 不同 —— 顶层的 key 直接就是每个 server 的名字,没有
mcpServers外层包裹,且每个 server 对象里需要带"type": "stdio"。
{
"tavily-firecrawl": {
"type": "stdio",
"command": "uvx",
"args": ["tavily-firecrawl-mcp"],
"env": {
"TAVILY_API_KEY": "tvly-xxxxxxxxxxxx",
"FIRECRAWL_API_KEY": "fc-xxxxxxxxxxxx",
"WEB_FETCH_PROXY": "http://127.0.0.1:7890"
}
}
}【可选】从 git 运行:
"args": ["--from", "git+https://github.com/bpx/tavily-firecrawl-mcp", "tavily-firecrawl-mcp"]
Claude Desktop / Claude Code(claude_desktop_config.json)
{
"mcpServers": {
"tavily-firecrawl": {
"command": "uvx",
"args": ["tavily-firecrawl-mcp"],
"env": {
"TAVILY_API_KEY": "tvly-xxxxxxxxxxxx",
"FIRECRAWL_API_KEY": "fc-xxxxxxxxxxxx",
"WEB_FETCH_PROXY": "http://127.0.0.1:7890"
}
}
}
}通用 stdio 客户端
{
"command": "uvx",
"args": ["tavily-firecrawl-mcp"]
}确保服务端继承的环境中已导出 TAVILY_API_KEY(以及可选的 FIRECRAWL_API_KEY / WEB_FETCH_PROXY)。
开发
pip install -e ".[dev]"
pytest许可证
MIT
Available Tools
2 toolsweb_fetchA
Fetch and extract the content of a web page as markdown (or plain text). Tries Tavily first; on failure or empty result, automatically falls back to Firecrawl. Requires TAVILY_API_KEY and/or FIRECRAWL_API_KEY in the server's environment.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| query | No | ||
| format | No | markdown | |
| extract_depth | No | basic | |
| only_main_content | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses fallback behavior and API key requirements, but lacks details on error handling (e.g., if both services fail), rate limits, or handling of dynamic content. Adequate but not comprehensive.
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 concise sentences: first states core purpose, second adds essential behavioral detail. No extraneous content, well-structured.
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?
Despite having an output schema (not shown), the description lacks crucial parameter explanations, error behavior, and auth specifics beyond key requirements. For a tool with 6 parameters and no schema descriptions, the description is too sparse to be complete.
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?
The input schema has 0% description coverage, and the tool description adds no information about any of the 6 parameters (url, query, format, extract_depth, only_main_content, timeout). The agent must rely solely on parameter names and defaults, which is insufficient for correct invocation.
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 the verb 'Fetch and extract' and the resource 'content of a web page', specifying output format (markdown/plain text). It also mentions fallback behavior, distinguishing it from sibling web_search which likely searches rather than fetches a specific URL.
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?
The description provides context for when to use by noting fallback to Firecrawl and required API keys. It doesn't explicitly state when not to use or compare to web_search, but the sibling context implies differentiation. A slight gap in explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchA
Search the web with Tavily and return titles, URLs, and snippets (plus an optional synthesized answer). No fallback — requires TAVILY_API_KEY in the server's environment.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No | ||
| search_depth | No | basic | |
| topic | No | general | |
| include_answer | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the API key dependency and the no-fallback behavior. It also hints at optional synthesis (include_answer). It does not cover rate limits or error handling, but the key requirement is a critical behavioral trait.
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, no filler, front-loaded with the core capability. Every clause adds value.
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?
Given 5 parameters and 0% schema coverage, the description is incomplete on parameter details. However, it covers the essential output and the critical dependency. The presence of an output schema reduces the need to describe return values.
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 coverage is 0%, so the description should compensate by explaining parameters. It only mentions that query is required and include_answer provides an optional answer, but leaves max_results, search_depth, and topic undocumented.
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 the action (search the web with Tavily) and the output (titles, URLs, snippets, optional answer). It distinguishes from the sibling tool web_fetch by its focus on search versus fetching a specific URL.
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?
The description explicitly states the environment requirement (TAVILY_API_KEY) and warns of no fallback, which guides when the tool is usable. However, it does not explicitly contrast with web_fetch or provide alternative scenarios.
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.
2 tool updates
v0.1.0- First observed
web_fetch - First observed
web_search
TDQS
Scored across 2 tools
web_fetch extracts page content as markdown, while web_search returns search results with titles and snippets. Their purposes are clearly distinct with no overlap.
Both tools follow a consistent verb_noun pattern using snake_case (web_fetch, web_search), making the naming predictable and clear.
With only 2 tools, the server feels minimal. While it covers the core operations of searching and fetching, the count is low for a combined service, though still functional.
The basic lifecycle of web content retrieval (search and fetch) is covered. Minor gaps include lack of explicit service selection or advanced options like pagination, but the main use cases are handled.
Maintenance
Related MCP Connectors
Scrape, crawl and search the web for AI agents via MCP.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Related MCP Servers
- FlicenseCqualityCmaintenanceBuilt as a Model Context Protocol (MCP) server that provides advanced web search, content extraction, web crawling, and scraping capabilities using the Firecrawl API.41-
- AlicenseAqualityBmaintenanceA Model Context Protocol server that enables web search, scraping, crawling, and content extraction through multiple engines including SearXNG, Firecrawl, and Tavily.4118 npm140MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables AI assistants to perform advanced web scraping, crawling, searching, and data extraction through the Firecrawl API.927,437 npmMIT
- -licenseBqualityNot gradedmaintenanceA Model Context Protocol compliant server that facilitates comprehensive web research by utilizing Tavily's Search and Crawl APIs to gather and structure data for high-quality markdown document creation.114 npm12-