Skip to main content
Glama

AIsa Web Search & Research

Execute a search query using Tavily Search.

post_tavily_search
Read-onlyIdempotent

Search the web and get back ranked results with the page text already extracted, so there is no second call to fetch content. query is required. Returns results[] with url, title, content (the extracted excerpt), score and optionally raw_content, alongside query, images, response_time and request_id; set include_answer to also get a one-paragraph answer. Filter with topic (general/news/finance), time_range or explicit start_date/end_date, and trade cost against depth with search_depth. Measured at roughly 6 seconds for 2 results. This is the default choice for open-web research, and the only search here that returns ranked results and page text in one call. Reach past it when: you already know the URLs — post_tavily_extract is cheaper and exact; the query is a description rather than keywords — post_exa_search matches on meaning; you want a written answer rather than a list to iterate — post_perplexity_sonar; you want peer-reviewed papers — post_scholar_search_scholar.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query to execute with Tavily.
topicNoCategory of the search.general
countryNoBoost search results from a specific country. Available only when topic is general.
end_dateNoReturn results before the specified end date.
start_dateNoReturn results after the specified start date.
time_rangeNoTime range to filter results based on publish date.
max_resultsNoMaximum number of search results to return.
safe_searchNoFilter out adult or unsafe content from search results. Enterprise only; not supported when search_depth is fast or ultra-fast.
search_depthNoControls the latency vs. relevance tradeoff. advanced gives the highest relevance with higher latency and cost; basic is balanced; fast and ultra-fast optimize for lower latency.basic
include_usageNoInclude credit usage information in the response.
include_answerNoInclude an LLM-generated answer. true uses the default answer mode; basic or advanced selects the answer generation mode.
include_imagesNoPerform an image search and include results.
auto_parametersNoAutomatically configure search parameters based on query content.
exclude_domainsNoList of domains to specifically exclude from the search results.
include_domainsNoList of domains to specifically include in the search results.
include_faviconNoInclude the favicon URL for each result.
chunks_per_sourceNoMaximum number of relevant chunks returned per source.
include_raw_contentNoInclude cleaned and parsed content for each search result. true or markdown returns markdown; text returns plain text and may increase latency.
include_image_descriptionsNoAdd descriptive text for each image when include_images is true.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and openWorld hints, but the description adds valuable behavioral context beyond them: it returns extracted text (eliminating a second call), measures roughly 6 seconds for 2 results, and trades cost against depth via search_depth. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-organized: it front-loads the core value (extracted text, no second call), then summarizes response shape, filtering options, and ends with clear alternative routing. Every sentence earns its place; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 19-parameter tool with a full output schema and rich annotations, the description covers the key behavior, performance, and selection criteria. It does not need to repeat the schema, and it addresses all critical decision points an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining that include_answer yields a one-paragraph answer, that start_date/end_date and time_range filter by publish date, and that search_depth trades cost against depth. These hints go beyond the schema's field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-resource pair ('Search the web') and immediately distinguishes this tool from siblings by noting it is the only one that returns ranked results and page text in one call. It explicitly says it extracts page content so no second fetch is needed, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly designates this as the default choice for open-web research and provides precise conditions for when to use alternatives: post_tavily_extract for known URLs, post_exa_search for semantic matching, post_perplexity_sonar for written answers, and post_scholar_search_scholar for papers. This is clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources