Skip to main content
Glama
robin-bially

search-rotation

by robin-bially
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Web Search

search_web
Read-onlyIdempotent

Search the web through rotating providers with automatic failover on errors, rate limits, or no quota. Use when you need current web pages and no URL is known.

Instructions

Search the web through a rotating pool of search providers (Tavily, Firecrawl, Parallel, Exa, Google PSE, DuckDuckGo) with automatic failover when one errors, is rate-limited or has no local quota left. Use it when the answer depends on current web pages and no URL is known yet; use fetch_url to read a page whose URL is already known. Returns numbered results (title, URL, snippet, publication date when the provider supplies one) and names the provider that answered plus every failed attempt, so failover stays visible. Time filters keep rotation inside the providers that implement them and fail explicitly instead of searching without the filter; if every eligible provider fails, the tool returns an error listing each provider's reason. The engine parameter only prefers a provider and leaves failover active.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query
engineNoPreferred engine id from get_engine_status; only moves that engine to the front, failover to the others stays active. Engines without implemented support for the time filter are skipped even when preferred.
endDateNoEnd date YYYY-MM-DD (through this date, subject to provider boundary semantics). Cannot combine with timeRange.
startDateNoStart date YYYY-MM-DD. May be used alone or with endDate; cannot combine with timeRange.
timeRangeNoRelative UTC date window: day=1, week=7, month=30, year=365 days through today. Cannot combine with startDate/endDate; day precision, not rolling hours.
numResultsNoOptional result count (1–20). Omit to use the dashboard setting: a custom count or the provider default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds substantial behavior beyond them: failover triggers (error, rate limit, no quota), the visibility of failed attempts, the explicit failure mode when time filters exclude all providers, and the fact that engine is only a preference. No contradiction with annotations.

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 with purpose, then usage routing, then return shape, then edge behaviors. Dense and largely waste-free, though the single long paragraph and some redundancy around failover keep it from being maximally tight.

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?

With no output schema, the description carries the burden and does: it describes the return shape (numbered results with title, URL, snippet, date, plus the answering provider and every failed attempt) and error behavior when all providers fail. Nothing essential for correct invocation is missing.

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, but the description adds real meaning the schema lacks: engine only moves a provider to the front while failover stays active, date vs timeRange mutual exclusion, and that numResults defaults to a dashboard setting. It stops short of documenting output ordering or result-merging semantics across providers.

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?

States a specific verb and resource (search the web) and names the mechanism (rotating provider pool with automatic failover), listing the providers. It explicitly distinguishes itself from the sibling fetch_url, so an agent can route correctly without opening either schema.

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?

Gives an explicit when-to-use rule ('when the answer depends on current web pages and no URL is known yet') paired with the contrasting condition for the alternative ('use fetch_url to read a page whose URL is already known'), plus guidance on what the engine parameter does and does not do.

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