Skip to main content
Glama
brightdata

Bright Data MCP

Official
by brightdata

search_engine_batch

Read-only

Execute multiple search queries simultaneously across Google, Bing, and Yandex, returning structured JSON or Markdown results for batch research.

Instructions

Run multiple search queries simultaneously. Returns JSON for Google, Markdown for Bing/Yandex.

Input Schema

NameRequiredDescriptionDefault
queriesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.9.3

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds genuinely non-obvious behavior — per-engine return formats (JSON for Google, Markdown for Bing/Yandex) — but says nothing about concurrency limits, per-query failure behavior, or whether one failing query aborts the batch.

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?

Two tight sentences with the purpose front-loaded and the format caveat second; nothing is padded. It is efficient but very short relative to how much of the schema is left unexplained.

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

Completeness3/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 does carry some of the return-value burden by naming formats per engine, which is helpful. However, it omits output shape, cursor/pagination semantics, and batch error handling — significant gaps for a multi-query tool.

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

Parameters2/5

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

Schema description coverage is effectively 0% beyond geo_location; the description explains none of the nested fields. The `cursor` parameter for pagination and the `engine` enum with its google default are undocumented, and the description does not mention the 1-5 query limit enforced by the schema.

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 ("Run multiple search queries simultaneously") and conveys batch semantics that implicitly separate it from the single-query search_engine sibling. It never names the sibling or the batch limit, so differentiation is inferred rather than explicit.

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

Usage Guidelines3/5

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

"Multiple ... simultaneously" implies the tool is for batching several queries, which hints at when to choose it over search_engine, but no explicit when/when-not rule or alternative is stated. An agent must infer the routing decision.

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