Click on "Install 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-fastmcp Search for recent articles about 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.
Typed, ergonomic FastMCP server for Tavily search, extract, map, crawl, and research workflows.
It ships with:
namespaced MCP tools like tavily.search and tavily.research
packaged prompt profiles and large markdown system prompts
static resources and dynamic resource templates for profiles, prompts, examples, and server catalogs
a small direct Python API for local use without MCP
docs, examples, CI, publishing workflow, coverage, Ruff, and mypy
langchain-tavily already gives you the raw Tavily tools. tavily-fastmcp adds a cleaner MCP boundary around them:
richer metadata for MCP clients
reusable profiles for common workflows
discoverable prompt and resource surfaces
stable typed request/response models you can test directly
easier LangChain + MCP composition
Tavily's official LangChain package provides the raw Tavily tools, and this package wraps them in a typed FastMCP server surface with prompts, resources, profiles, and example client configuration.
Related MCP server: tavily-mcp
pdm add tavily-fastmcpFor LangChain helpers:
pdm add "tavily-fastmcp[langchain]"For LangGraph workflows:
pdm add "tavily-fastmcp[langchain]" langgraphWith uv:
uv add "tavily-fastmcp[langchain]" langgraphFor docs and development:
pdm install -G :allTavily uses the TAVILY_API_KEY environment variable. This package preserves that variable directly and layers package-specific settings under the TAVILY_FASTMCP_ prefix.
cp .env.example .envPut real keys only in .env; it is ignored by Git. Keep .env.example as placeholders.
To run the opt-in live smoke test:
make test-livetavily-fastmcpOr:
python -m tavily_fastmcp.server --transport stdiofrom tavily_fastmcp.service import LangChainTavilyService
from tavily_fastmcp.settings import get_settings
service = LangChainTavilyService(get_settings())
response = service.search_from_model(query="latest FastMCP prompts docs")
print(response.results[0].url)from tavily_fastmcp.server import create_server
server = create_server()import asyncio
from langchain.agents import create_agent
from langchain_mcp_adapters.client import MultiServerMCPClient
async def main() -> None:
client = MultiServerMCPClient(
{
"tavily": {
"command": "python",
"args": ["-m", "tavily_fastmcp.server", "--transport", "stdio"],
"transport": "stdio",
}
}
)
tools = await client.get_tools()
agent = create_agent(model="openai:gpt-5", tools=tools)
result = await agent.ainvoke(
{
"messages": [
{
"role": "user",
"content": "Research the best docs pages for FastMCP resource templates.",
}
]
}
)
print(result)
asyncio.run(main())Use MCP when you want the model to choose among Tavily search, extract, map, crawl, and research tools at runtime:
import asyncio
from langchain.agents import create_agent
from langchain_mcp_adapters.client import MultiServerMCPClient
async def build_agent():
client = MultiServerMCPClient(
{
"tavily": {
"transport": "stdio",
"command": "python",
"args": ["-m", "tavily_fastmcp.server", "--transport", "stdio"],
"env": {"TAVILY_API_KEY": "tvly-your-key-here"},
}
}
)
tools = await client.get_tools()
return create_agent(
model="openai:gpt-5",
tools=tools,
system_prompt=(
"Use Tavily for current web research. Prefer tavily.search for broad "
"discovery, tavily.extract for source reading, and tavily.research "
"when a synthesized report is requested."
),
)
async def main() -> None:
agent = await build_agent()
result = await agent.ainvoke(
{
"messages": [
{
"role": "user",
"content": "Compare three recent MCP client patterns and cite sources.",
}
]
}
)
print(result)
asyncio.run(main())Use LangGraph when you want explicit state transitions around the Tavily MCP tools, such as adding review, persistence, retries, or a human approval step.
import asyncio
from langchain_openai import ChatOpenAI
from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.graph import START, MessagesState, StateGraph
from langgraph.prebuilt import ToolNode, tools_condition
async def main() -> None:
client = MultiServerMCPClient(
{
"tavily": {
"transport": "stdio",
"command": "python",
"args": ["-m", "tavily_fastmcp.server", "--transport", "stdio"],
"env": {"TAVILY_API_KEY": "tvly-your-key-here"},
}
}
)
tools = await client.get_tools()
model = ChatOpenAI(model="gpt-5").bind_tools(tools)
async def call_model(state: MessagesState) -> dict:
response = await model.ainvoke(state["messages"])
return {"messages": [response]}
graph_builder = StateGraph(MessagesState)
graph_builder.add_node("agent", call_model)
graph_builder.add_node("tools", ToolNode(tools))
graph_builder.add_edge(START, "agent")
graph_builder.add_conditional_edges("agent", tools_condition)
graph_builder.add_edge("tools", "agent")
graph = graph_builder.compile()
result = await graph.ainvoke(
{
"messages": [
{
"role": "user",
"content": "Map the FastMCP docs site and identify the pages about prompts.",
}
]
}
)
print(result["messages"][-1].content)
asyncio.run(main())Use tavily.search for broad discovery, current facts, and source finding.
Use tavily.extract after search when the agent needs page text from known URLs.
Use tavily.map to discover a site's URL structure before targeted extraction.
Use tavily.crawl when the agent must inspect multiple pages from one domain.
Use tavily.research for multi-source synthesized reports.
Use tavily.catalog and profile resources when an agent needs to learn the
available tools and prompt profiles before deciding how to route a task.
The package ships with large markdown prompts and reusable profiles for:
router
suite-overview
quick-search
tool-search
extract-and-summarize
tool-extract
site-discovery
tool-map
site-crawl
tool-crawl
deep-research
tool-research
tool-get-research
routing-matrix
synthesis-policy
mcp-usage-guide
They are exposed both as packaged markdown files and as MCP resources / prompts. The richer catalog now also includes a composite suite overview, per-tool deep guides, a routing matrix, a synthesis policy, and an MCP usage guide.
Example URIs:
resource://tavily-fastmcp/catalog/server
resource://tavily-fastmcp/catalog/profiles
resource://tavily-fastmcp/profile/deep-research
resource://tavily-fastmcp/prompt/router
resource://tavily-fastmcp/prompt/deep-research
resource://tavily-fastmcp/example/claude-desktop-config
The server is organized so MCP clients can discover tools, prompts, resources, examples, and workflow profiles through namespaced metadata and resource URIs.
tavily.health
tavily.catalog
tavily.search
tavily.extract
tavily.map
tavily.crawl
tavily.research
tavily.get_research
All tools use typed arguments, tags, annotations, titles, and custom metadata.
Claude Code can run this package as a local stdio MCP server. Keep the Tavily key in your shell or project secret manager, then add the server:
export TAVILY_API_KEY="tvly-your-key-here"
claude mcp add tavily-fastmcp --scope project \
--env TAVILY_API_KEY="$TAVILY_API_KEY" \
-- python -m tavily_fastmcp.server --transport stdioUseful checks:
claude mcp list
claude mcp get tavily-fastmcpFor a checked-in Claude Code project config, use .mcp.json with environment
expansion so secrets stay outside Git:
{
"mcpServers": {
"tavily-fastmcp": {
"type": "stdio",
"command": "python",
"args": ["-m", "tavily_fastmcp.server", "--transport", "stdio"],
"env": {
"TAVILY_API_KEY": "${TAVILY_API_KEY}"
}
}
}
}{
"mcpServers": {
"tavily-fastmcp": {
"command": "python",
"args": ["-m", "tavily_fastmcp.server", "--transport", "stdio"],
"env": {
"TAVILY_API_KEY": "tvly-your-key-here"
}
}
}
}{
"name": "tavily-fastmcp",
"command": "python",
"args": ["-m", "tavily_fastmcp.server", "--transport", "stdio"],
"env": {
"TAVILY_API_KEY": "tvly-your-key-here"
}
}Install everything:
pdm install -G :allRun the standard checks:
make lint
make type
make test
make docsEquivalent PDM commands:
pdm run ruff check .
pdm run mypy src
pdm run pytest
pdm run sphinx-build -b html docs/source docs/source/_build/htmlmake docsThe documentation is grouped under:
docs/source/usage/: MCP, direct Python, and LangChain usage.
docs/source/guides/: development, automation, and publishing workflows.
docs/source/reference/: configuration, tools, and profiles.
Publishing is intended to run through GitHub Releases and PyPI trusted publishing.
Configure the PyPI trusted publisher for repository pr1m8/tavily-fastmcp and
workflow file release.yml with environment pypi.
If PyPI trusted publishing is not ready yet, add a PyPI API token as the GitHub
secret PYPI_API_TOKEN; the release workflow will use it before falling back to
OIDC. For the first upload of a brand-new PyPI project, this may need to be an
account-scoped token. Rotate it to a project-scoped token after the project
exists.
Use the local publish gate before tagging:
make publish-checkThen create and push a version tag such as v0.3.1, publish the GitHub Release,
and let the Release workflow upload distributions to PyPI. The local
make publish target prints the release flow and does not upload packages.
This project now includes GitHub automation for the full package lifecycle:
CI runs linting, typing, and tests on pushes and pull requests.
Docs builds the Sphinx site and uploads the rendered HTML as an artifact.
Build creates source and wheel distributions and validates them with twine check.
Release rebuilds the distributions on GitHub Releases and publishes them to PyPI using trusted publishing.
.readthedocs.yaml configures Read the Docs to build the Sphinx documentation with Python 3.13.
Return the structured server catalog that describes tools, resources, and prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| version | Yes | |
| package_name | Yes | |
| prompt_names | No | |
| profile_slugs | No | |
| tool_names | No | |
| resource_uris | No | |
| example_resource_uris | No | |
| meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds value by specifying what the catalog contains (tools, resources, prompts). No contradictions.
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?
The description is a single, well-structured sentence with no wasted words. It conveys the essential purpose efficiently.
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 the tool's simplicity, optional parameter, and presence of an output schema, the description is sufficiently complete. It does not need to elaborate on 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?
The only parameter 'ctx' is fully described in the input schema (100% coverage). The description adds no additional meaning beyond what the schema 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 the action ('Return') and the resource ('structured server catalog'), and the scope ('describes tools, resources, and prompts') differentiates it from sibling tools like crawl, extract, or research.
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 no guidance on when to use this tool versus alternatives like the other tavily tools. It does not mention when not to use it or offer any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Traverse a site and retrieve multi-page content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Root URL to begin crawling. | |
| instructions | No | Optional crawling guidance. | |
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| base_url | No | |
| results | No | |
| request_id | No | |
| response_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds the multi-page scope but lacks details on crawling depth, rate limits, or behavior on large sites. It does not contradict annotations.
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?
A single, front-loaded sentence with no wasted words. Every word earns its place.
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 the output schema and rich annotations, the description is fairly complete for a straightforward crawling tool. However, it could mention depth or limits.
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 has 100% coverage with descriptions for url and instructions. The description adds no extra meaning beyond what is already in the schema, so baseline 3 applies.
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 uses specific verbs 'Traverse' and 'retrieve' and identifies the resource as 'site' and 'multi-page content'. It clearly distinguishes from siblings like tavily.search or tavily.extract.
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 implies usage for multi-page content retrieval from a root URL, but does not explicitly state when not to use it or mention alternative tools for single-page extraction or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract content from specific known URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs to extract. | |
| extract_depth | No | Extraction depth. | basic |
| include_images | No | Include image metadata. | |
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| results | No | |
| failed_results | No | |
| response_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, indicating safe read operations. The description adds minimal behavioral context beyond stating it extracts content, which is adequate but not rich.
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?
Single sentence of 8 words, perfectly front-loaded, no wasted words.
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 the output schema, annotated safety, and fully described parameters, the description is complete for this simple read operation.
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 100% with descriptions for each parameter. The description does not add extra meaning beyond what the schema provides, meeting the baseline for high coverage.
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?
Description clearly states the verb 'extract' and the resource 'content from specific known URLs', distinguishing it from sibling tools like tavily.search (search) and tavily.crawl (crawl).
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?
While not explicit about when-not-to-use, the description 'extract content from specific known URLs' clearly implies the tool is for known URLs, contrasting with siblings for search or crawling. The context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the status or result of an existing Tavily research task.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | Tavily research request identifier. | |
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| request_id | No | |
| created_at | No | |
| completed_at | No | |
| status | No | |
| input | No | |
| model | No | |
| content | No | |
| sources | No | |
| response_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description's role is lighter. It correctly adds that the tool retrieves status/result, aligning with annotations. No contradictions.
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?
Single efficient sentence with no extraneous words. Front-loaded with the key purpose.
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 the presence of an output schema and full annotations, the description is complete for this simple retrieval tool. No further details needed.
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 100%, so the schema fully describes the request_id and ctx parameters. The description adds no extra semantic value beyond the schema.
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 tool retrieves status/result of an existing research task, with a specific verb and resource. It distinguishes from siblings like tavily.research (likely creation) and tavily.search.
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 implies usage for checking existing tasks but gives no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like tavily.research.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return package and server health metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| server_name | Yes | |
| version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint; description adds context about the scope of health metadata (package and server). No contradictions.
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?
Single sentence, front-loaded, no wasted words.
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 low complexity, presence of output schema, and clear purpose, the description is sufficiently complete for a health check 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 coverage is 100% with a well-described 'ctx' parameter; description adds no additional parameter semantics beyond what the schema 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 the verb 'Return' and the resource 'package and server health metadata', distinguishing it from sibling tools like tavily.search or tavily.crawl.
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?
No explicit guidance on when to use this tool versus alternatives; usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover site structure and candidate URLs on a single domain.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Root URL to map. | |
| instructions | No | Optional mapping guidance. | |
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| base_url | No | |
| results | No | |
| request_id | No | |
| response_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint. Description adds that it discovers site structure on a single domain, which is useful but does not go beyond annotation coverage.
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?
Single, front-loaded sentence that conveys purpose efficiently with zero waste.
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 simple tool with strong annotations and output schema, description is adequate but lacks usage context or behavioral details.
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 100% with parameter descriptions. The tool description adds no additional meaning beyond what the schema 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?
Description clearly states the verb 'discover', the resource 'site structure and candidate URLs', and scope 'on a single domain'. This distinguishes it from sibling tools like tavily.search or tavily.crawl.
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?
No explicit guidance on when to use this tool versus alternatives. No exclusion criteria or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deep multi-source Tavily research task.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Research task or question. | |
| model | No | Research model. | auto |
| citation_format | No | Citation format. | numbered |
| stream | No | Whether Tavily should stream results. | |
| output_schema | No | Optional JSON schema for structured output. | |
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| request_id | No | |
| created_at | No | |
| completed_at | No | |
| status | No | |
| input | No | |
| model | No | |
| content | No | |
| sources | No | |
| response_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, indicating no side effects. The description adds that the research is 'deep multi-source', which is useful but does not conflict with annotations. With annotations already covering safety, the description provides adequate but minimal additional behavioral context.
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?
The description is a single sentence that is clear and efficient. While it is concise, it could benefit from slightly more detail without becoming verbose.
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 the complexity of the tool (6 parameters, multiple siblings), the description is too minimal. It does not explain how a research task differs from other tools or what workflow to expect. The presence of an output schema partially compensates, but the description remains incomplete.
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 100%, so parameters are well-documented in the schema. The tool description does not add any extra meaning or context to the parameters beyond what is already in the schema.
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?
Description clearly states the tool creates a deep multi-source research task, indicating it's more comprehensive than a simple search. However, it does not explicitly distinguish from sibling tools like tavily.search or tavily.extract, so it falls short of a 5.
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?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without any context on prerequisites, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web when relevant URLs are not yet known.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language web search query. | |
| max_results | No | Maximum number of results. | |
| topic | No | Search topic mode. | general |
| include_answer | No | Include Tavily's answer field. | |
| include_raw_content | No | Include cleaned page content. | |
| include_images | No | Include image URLs. | |
| include_image_descriptions | No | Include image descriptions. | |
| search_depth | No | Tavily search depth. | basic |
| time_range | No | Relative publish-date filter. | |
| start_date | No | Inclusive start date in YYYY-MM-DD format. | |
| end_date | No | Inclusive end date in YYYY-MM-DD format. | |
| include_domains | No | Domains to include. | |
| exclude_domains | No | Domains to exclude. | |
| include_usage | No | Include usage metadata. | |
| ctx | No | Optional FastMCP context. |
| Name | Required | Description |
|---|---|---|
| query | No | |
| answer | No | |
| results | No | |
| images | No | |
| response_time | No | |
| request_id | No | |
| follow_up_questions | No | |
| usage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only, idempotent, and open-world behavior. The description adds no additional behavioral context (e.g., rate limits, pagination, or result composition). With annotations covering safety, the description falls short of enhancing transparency beyond the structured data.
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?
The description is a single, concise sentence that immediately conveys the core purpose. It is efficient but could be slightly restructured to include a brief mention of key features or output without losing brevity.
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, the description is too sparse for a tool with 15 parameters and complex filtering capabilities. It does not indicate the rich set of options (date range, domains, depth) available, leaving agents unaware of the tool's full potential.
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 100%, with each parameter having a description. The tool description itself does not elaborate on parameters, but the schema already does so adequately. Baseline score of 3 is appropriate given the high schema coverage.
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 tool performs web searches when URLs are not known, distinguishing it from siblings like 'extract' (which requires URLs). However, it does not explicitly mention the return of search results or snippets, which would further clarify its purpose.
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 a clear usage context ('when relevant URLs are not yet known'), implying when to use this tool versus others like 'extract' or 'crawl'. However, it lacks explicit guidance on when not to use it or direct comparisons with sibling tools, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: catalog and health are meta; crawl, extract, map, search, research, and get_research each target different research stages. No overlap.
All tools follow a consistent 'tavily.<verb>' or 'tavily.get_research' pattern with snake_case, making the naming predictable.
8 tools is well within the ideal 3-15 range, and each tool serves a necessary function in the research workflow.
The tool set covers the full lifecycle: search for unknown URLs, map/extract/crawl for content, research for deep analysis, and get_research for results, plus health and catalog for metadata. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scrape, crawl and search the web for AI agents via MCP.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pr1m8/tavily-fastmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server