MCP server that provides Persian web search capabilities using Selenium and web scraping, designed to augment offline LLMs with real-time search results
Single tool 'research' has a minimal description (89 chars, below baseline 194) and lacks parameter descriptions entirely. Input schema exists but is bare-bones: only 'query' with generic string type and no constraints (enums, length limits, format). No output schema documented. No error handling guidance. Tool name 'research' is generic and does not follow verb_noun convention (should be 'search_persian_web' or similar). No indication of pagination, result limits, or structured response format in the schema. The implementation shows sophisticated logic (Selenium scraping, content extraction, link filtering) but none of this is reflected in the tool definition exposed to the LLM.
Search the Persian web. Returns 10 sources (800 chars each). Call with a short Persian query.
Tool name 'research' is generic and does not follow verb_noun convention. Should be 'search_persian_web' or 'search_web' to clearly signal the action and domain.
Input parameter 'query' lacks description. LLM cannot infer that it expects Persian text, short queries, or any constraints. Parameter descriptions are mandatory per pattern:tool-description.
No output schema documented. LLM does not know what fields to expect (e.g., title, url, snippet, source_count). Without documented return structure, downstream tool chaining is impossible.
Tool description (89 chars) is below baseline (194 chars) and lacks WHAT/WHEN/WHY context. Does not explain when to use this vs other search tools, what 'Persian web' means, or what '10 sources (800 chars each)' implies about result structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 25 | 2026-07-28+ | v2 |
No error handling guidance. Implementation shows retry logic, timeouts, and blocked domains, but tool definition provides no recovery hints. If a search fails, LLM has no guidance on what to do next.