Free API-keyless web search and visible Chrome automation for AI agents over MCP.
Web Search Neo demonstrates solid tool definition quality with complete input schemas, clear descriptions, and thoughtful parameter design. All 6 tools have explicit JSON Schema definitions with proper types and descriptions. Tool names follow verb_noun conventions (fetch_*, search_*, get_*). Descriptions are detailed and context-aware, averaging ~150-200 characters. However, output schemas are not formally documented, the server returns results but LLM context about response structure must be inferred. Security considerations (file path confinement, timeout caps, overwrite safeguards) are well-designed. Error handling is implicit but not explicitly guided (no recovery suggestions in descriptions). Tool composition is solid: each tool has a single, clear responsibility, and parameters are well-constrained with enums and defaults.
Return de-duplicated absolute links without blocking parallel calls.
Download an HTTP(S) page without blocking parallel MCP tool calls. mode='raw'/'html' returns the raw source (JS bundles, markup); headers sends custom request headers; save_to writes the body to a file under WEB_SEARCH_NEO_DOWNLOAD_DIR (default ./downloads) and never replaces an existing file unless overwrite=true. timeout_seconds is capped at 120.
Fetch up to 16 pages concurrently and return text or an error per URL.
List search engines and optionally check their live availability in parallel.
Send any HTTP request without a browser; 4xx/5xx return status and body, not errors. save_to is confined to WEB_SEARCH_NEO_DOWNLOAD_DIR (default ./downloads) and needs overwrite=true to replace a file; timeout_seconds is capped at 120.
Search with immediate fallback, or allow a three-minute manual challenge handoff.
Output schemas not formally documented. While input schemas are complete and correct, tool responses lack explicit schema definitions. LLMs cannot plan downstream operations without knowing what fields to expect (e.g., does fetch_url_text return {text, length, url} or {content, metadata}?). This forces inference from descriptions or trial-and-error.
Error handling guidance missing. Tool descriptions do not explain what errors can occur, what they mean, or how to recover. Example: search_web mentions 'challenge_mode' fallback but does not document failure modes, timeout behavior, or fallback engine selection logic.
fetch_page_links description is minimal (17 chars: 'Return de-duplicated absolute links without blocking parallel calls'). While grammatically complete, it lacks actionable context: What format are the links? Are they filtered by domain? What's the use case?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
Parameter 'headers' lacks specificity. Appears in fetch_url_text, fetch_page_links, fetch_urls_text, and http_request. Description 'Custom HTTP headers' does not explain format (object keys = header names?), constraints (no Authorization?), or examples.
Timeout cap not self-evident from schema. 'timeout_seconds is capped at 120' is explained in fetch_url_text description text, but not in the parameter schema itself. An LLM reading only the schema (timeout_seconds: {type: number}) will not know the hard limit.