Skip to main content
Glama

Web Search

search
Read-onlyIdempotent

Query the web for ranked results with titles, URLs, snippets, and optional synthesized answers; filter by recency, language, or domains and choose free or paid providers.

Instructions

Search the web. Returns ranked results with titles, URLs and content snippets, and -- depending on the provider -- a synthesised answer with the sources backing it.

Every call reaches a live provider, and most of them are billed, so search when you need information you don't already have. The names that cannot bill are exa:free and parallel:free (rate-limited anonymous endpoints), searxng (the operator's own instance), tinyfish (free at any balance) and freeserp (a keyless web index). Naming one of them costs the operator nothing; every other name is billed, immediately or once the free allowance on that account runs out. mode="free" restricts a search to those names and fails rather than falling back to a paid provider, so a free-only search can come back with nothing.

A result carries either a short snippet or, from a content backend, a longer page extract in text. The extract is bounded, so text_truncated marks a result whose page continues past what you were given -- fetch that URL when the rest would change your answer, and not otherwise.

provider selects which backend runs the search. Omit it to use the server's default; if the default fails, the server retries the fallbacks configured for it and names the substitute in notice. A deployment where every enabled provider is one that cannot bill and no default is configured has no price to guess at, so omitting provider there is served from that free set instead of being refused. Naming a provider returns results from exactly that provider or an error. mode="free" is the other way to choose -- a class of provider rather than one by name -- and the two cannot be combined. Providers differ in what they return and what filters they honour: if one cannot apply a filter you passed, the response says so in notice rather than pretending it did. When a response carries an answer, that is provider-written prose -- verify it against results rather than citing it directly.

Input Schema

NameRequiredDescriptionDefault
modeNoRoute the search through free providers only. The names that cannot bill are `exa:free` and `parallel:free` (rate-limited anonymous endpoints), `searxng` (the operator's own instance), `tinyfish` (free at any balance) and `freeserp` (a keyless web index). The server fails rather than escalating to a paid provider, so a free-only search can come back with nothing. Not every one is enabled on every deployment. Mutually exclusive with `provider`.
queryYesThe search query. Natural-language questions work well.
recencyNoRestrict results to pages published in the last day, week, month or year. A provider without a date filter says so in `notice` rather than pretending it filtered.
languageNoThe language results should be in, as an ISO 639-1 code (`en`, `de`); a region is `country`'s job and this field does not take one. A provider with no language parameter says so in `notice` rather than pretending it filtered.
providerNoWhich search backend to use. Omit to use the server's default; if that fails, the server retries the fallbacks its operator configured and says so in `notice`. A deployment where every enabled provider is free and no default is configured has no price to guess at, so an omitted `provider` there is served by that free set instead of refused. Naming a provider gets exactly that provider or an error. Not every provider is enabled on every deployment.
max_resultsNoMaximum number of results. Keep this low unless you need breadth; each result costs context.
safe_searchNo`true` asks the backend to filter adult content, `false` asks it not to; omitting it means the server does not override the provider's own default, which is not the same as unfiltered. A provider without the parameter says so in `notice`.
exclude_domainsNoOmit results from these domains.
include_domainsNoRestrict results to these domains, e.g. ["arxiv.org"].

Output Schema

NameRequiredDescriptionDefault
queryYes
answerNo
noticeNo
resultsYes
providerYes
retrieved_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already establish read-only, open-world, and idempotent behavior, but the description adds substantial operational context: live billed provider calls, free provider set, mode='free' failure semantics, provider fallback notices, filter-not-honored notices, answer verification, and text_truncated/fetch guidance. There is no annotation contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Front-loaded and well structured, but long and repeats some provider/free-mode details already present in the schema, especially the free-provider list. The density is mostly justified by billing and fallback complexity, though it could be tighter.

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?

Given 9 parameters, live-provider variability, annotations, and an output schema, the definition covers the operational details an agent needs: cost, fallback, notices, truncation, and answer provenance. Nothing major is missing for correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds cross-parameter semantics: provider vs mode mutual exclusivity, omitted-provider fallback, free-only failure rather than paid escalation, and provider-specific notice behavior. This is more than restating schema field descriptions.

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

Purpose4/5

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

States a specific verb and resource and describes the return format ('ranked results with titles, URLs and content snippets'), which is more than a restatement. It differentiates from fetch by telling the agent to fetch truncated URLs, but never explicitly separates this tool from the sibling answer tool.

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

Usage Guidelines4/5

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

Gives practical when-to-use guidance ('search when you need information you don't already have'), billing and free-provider constraints, provider-vs-mode exclusivity, and fallback behavior. It does not explicitly say when to use answer instead, so the sibling routing is incomplete.

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

Deploy Server

Other Tools