MCP Server for ZENO Browser - AI-powered web browser with web search and content processing capabilities
Single tool 'web_search' has a basic schema with two parameters (query, max_results) but critical gaps undermine quality. Description is minimal (11 words, ~60 chars), below the 10 - 1024 char baseline and lacks WHEN/WHY context. Parameter 'max_results' is marked optional but has no type constraint (number range), no enum, no default. Query parameter lacks format guidance. No output schema documented, LLMs cannot plan downstream calls or extract structured data. No error handling guidance (e.g., what if Tavily API fails? Rate limited?). Tool does not follow verb_noun naming (web_search is acceptable but generic). No indication of pagination support, result limits, or field structure returned. Composition risk: if this is part of a larger agent system, downstream tools cannot chain on undocumented response fields.
Search the web using Tavily search API
No output schema documented. LLMs cannot infer what fields are returned (e.g., title, url, snippet, source). Breaks tool chaining and forces agents to guess response structure.
Description is 60 characters (~11 words). Baseline is 194 chars. Lacks WHEN to use, prerequisites, and what data is returned. LLMs cannot determine if this is the right tool for a query.
Parameter 'max_results' has no type constraint, range (min/max), or default. Unbounded numbers let LLMs pass absurd values (e.g., 999999) that break APIs or cause timeouts.
No error handling guidance. If Tavily API fails, rate-limits, or returns no results, LLM has no recovery path. Missing pattern: recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
No pagination or result limit documented. If Tavily returns 100+ results, response bloats context window. Baseline: cap at 20 - 50 and offer pagination.