Skip to main content
Glama
wxs-lang

webscout-mcp

by wxs-lang

web_search

Search the web without an API key and get structured results. Automatic provider fallback and health-based ranking ensure reliable responses; invalid queries are rejected to save calls.

Instructions

Search the web and return structured results.

SearchService uses health-based provider ranking, deterministic recovery classification, and automatic fallback across registered search providers. Empty/invalid queries are rejected without network calls. No API key required for the default HTML providers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
regionNowt-wt
max_resultsNo
safe_searchNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does add meaningful behavior: it rejects empty/invalid queries without network calls, uses automatic fallback, and requires no API key for default providers. However, it omits rate limits, failure modes, and result ordering, so transparency is only partial.

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?

The purpose is front-loaded in the first sentence, and the remaining three sentences are relatively compact. The phrase 'deterministic recovery classification' is somewhat jargon-heavy, but overall the description is not bloated.

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?

The description plus schema provides basic context: an output schema exists, and the description explains provider selection and prerequisites. But because parameter semantics are absent and usage guidance is missing, an agent could still misuse region or max_results, so completeness is mediocre.

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?

The input schema has 0% semantic coverage and the description only indirectly addresses the query parameter through 'Empty/invalid queries rejected.' It says nothing about region format/values, max_results limits, or safe_search behavior, so it fails to compensate for the schema gap.

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?

The description opens with 'Search the web and return structured results,' naming a specific verb and resource clearly. However, it does not explicitly distinguish itself from siblings like web_crawl or web_extract, so differentiation is partial.

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

Usage Guidelines2/5

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

No guidance is provided on when to use web_search versus alternatives such as web_fetch, web_crawl, or web_extract. The implementation details about provider ranking and fallback do not help an agent select between tools.

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