MCP Server for ZERONOVA LAB tools — SEO audit, link checking, OGP validation, config file generation, and more for AI agents
Scoring was not performed
Output schemas not documented in tool definitions. Zod validators exist in code (e.g., altCheckerResponseSchema, speedCheckerResponseSchema in src/client.ts) but are not exposed to MCP clients. LLMs cannot see what fields to expect from each tool, preventing effective tool chaining and downstream planning.
Parameter descriptions are minimal. All 16 tools accept only a 'url' or 'projectPath' string parameter with a description of what resource to check, but lack guidance on expected format, constraints, or failure modes. E.g., 'speed_checker' accepts a 'strategy' enum (mobile|desktop) but the enum is buried in schema, not explained in description. Parameter validation happens at API layer but error messages are not documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 22 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Naming convention inconsistent with production baselines. Tools are named 'X_checker' or 'check_X' (e.g., alt_checker, check_api_auth) but lack explicit action verbs in some cases. The pattern 'verb_noun' (audit_, verify_, validate_) would better signal intent than passive '_checker' suffix. 'check_injection_risk' is good; 'heading_extractor' is acceptable but 'extract_headings' would be clearer.
Error handling and recovery guidance absent. API client (src/client.ts) implements retry logic with 15s timeouts and ApiError class, but tool definitions do not document what errors can occur or how to recover. No guidance for LLMs on whether timeouts are retryable, whether network errors are transient, or what to do if a URL returns 404. Pattern: recovery-guide not implemented.
No pagination or result limits documented. Tools like 'link_checker' and 'image_checker' may return hundreds of items, but tool definitions do not mention pagination, limits, or how to handle large result sets. LLMs have no way to know if results are capped or incomplete, risking context window exhaustion.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 16 tools are read-only (no state changes), which is correct, but this is not explicitly declared in tool metadata. Missing annotations prevent MCP clients from optimizing retries and caching.