Loading ToolBench
FOSS zero-cost, agent-first SEO & GEO search radar CLI powered by TypeSafe Jev
This STDIO-only MCP server for SEO tooling exposes 14 tools with significant definition quality gaps. While most tools have basic descriptions (10-50 chars), input schemas are either completely absent or severely incomplete. Parameter descriptions are minimal or missing entirely. The tool names follow imperative conventions (keywords, query, audit, crawl, etc.) but many lack sufficient clarity in descriptions to guide LLM selection. Output schemas are not documented anywhere in the visible code. Error handling is absent from tool definitions. Security considerations (API keys, paid services) are mentioned in descriptions but not integrated into the tool design (e.g., TAVILY_API_KEY, firecrawl keys are referenced as environment variables, not properly gated). No tool annotations (readOnlyHint, destructiveHint) are present despite several tools performing destructive operations (rank writes to SQLite). The 'mcp' tool appears to be a meta-command to launch the MCP server itself, not a typical tool exposed via MCP.
Audit a local file or directory for on-page SEO issues, duplicate titles, and thin pages
Synthesize live SERP competitor results into a ready-to-write content brief
Crawl a live site for broken links, redirect chains, and orphan pages
Check environment: version, API key presence, database, platform
Generative Engine Optimization (GEO) citation scoring via Jev
Google Search Console: free first-party query data (auth, sites, query)
Autocomplete keyword discovery & intent classification
Output schemas not documented for any tool. LLMs cannot know what fields to expect in responses, preventing downstream tool chaining and multi-step planning.
Parameter descriptions are minimal or missing for many tools. LLMs cannot infer parameter semantics from names alone. E.g., 'target' appears in geo, schema, and sitemap with different meanings; 'query' in keywords means autocomplete input, while in query/brief/gsc means SERP query, no distinction in names.
Enum constraints not formalized in schemas. 'provider' (query), 'depth', 'topic', 'fetch', 'op' (gsc) contain example values in descriptions instead of formal enum definitions. LLMs may hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Check llms.txt presence and AI crawler permissions for answer-engine readiness
Start native stdio JSON-RPC 2.0 Agent MCP Server
Scrape live SERP competitors and analyze winning content gaps
Track domain rankings in local SQLite (.jev-seo.db)
Inspect robots.txt on a live domain for AI crawler permissions and sitemaps
Validate Schema.org JSON-LD markup against active 2026 search specifications
Inspect and validate XML sitemaps for protocols, URL limits, and hreflang
No error handling or recovery guidance documented. Tools that call external APIs (query, brief, crawl, gsc) can fail, but no error messages or recovery paths are defined. LLMs have no guidance on retrying or alternative tools.
Destructive operations lack tool annotations and confirmation mechanisms. 'rank' writes to SQLite but has no readOnlyHint=false annotation, idempotentHint declaration, or dry-run option. Agents may accidentally overwrite data.
API keys and secrets referenced in descriptions but not gated. 'TAVILY_API_KEY', 'firecrawl' keys are mentioned as environment variables, but tool parameters don't hide or protect them. Secrets may leak into agent traces and prompt history.
Overloaded parameters with context-dependent meanings. 'site' param in gsc accepts device code OR URL depending on 'op' value. 'target' in schema, geo, sitemap have different interpretations. This ambiguity forces LLMs to guess.
Tool naming lacks clarity for domain-specific acronyms and ambiguous verbs. 'geo' is not self-documenting (Generative Engine Optimization?). 'doctor' is generic. 'gsc' is unexplained. 'mcp' is a meta-command, not a tool.
Pagination and result limits not documented. Tools like 'query' (limit default=10), 'brief' (limit default=5), 'crawl' (max_pages=50), 'gsc' (limit default=10) have defaults, but no guidance on what happens when results exceed limits or how to fetch next pages.
Multi-mode tools blur single responsibility. 'gsc' tool has three sub-operations (auth, sites, query) controlled by 'op' param. This should be split into separate tools (gsc_auth, gsc_sites, gsc_query) or clearly documented as a multi-step workflow.