CLI and MCP server for DataForSEO API — browse documentation and make authenticated API requests
DataForSEO MCP server demonstrates solid definition quality with all 4 tools properly named, described, and schema-validated. Tools follow verb-noun patterns (docs_index, docs_list_sections, docs_search, api_request) and descriptions are clear and actionable (avg 65-120 chars). All parameters have type definitions and descriptions. However, output schemas are not documented in the visible code, responses are not formally declared, only inferred from implementation. The api_request tool is unusually complex with overlapping parameters (path vs url, noAiMode affecting response structure), creating potential confusion. No critical security issues detected (credentials injected server-side), but error handling relies on exception messages rather than structured recovery guidance.
Make an authenticated request to the DataForSEO API
Fetch the DataForSEO API documentation index (llms.txt), optionally filtered by section
Return available DataForSEO API documentation section names
Fetch DataForSEO API documentation from a documentation URL
Output schemas not documented. While all input schemas use Zod with clear types and descriptions, tool responses lack formal schema declarations. LLMs cannot predict response structure or plan downstream operations. This violates the 'document the output schema' critical check.
api_request parameter ambiguity: both 'path' and 'url' are optional, but one is required. No enum constraint or mutual-exclusion documentation guides the LLM. Additionally, 'noAiMode' changes response structure semantics (full vs ai-optimized), which LLMs may not model correctly without explicit return type documentation.
Error handling lacks recovery guidance. Code shows generic exception catches (z.ZodError, generic Error) with simple error messages. No categorization (retryable vs user-fixable vs fatal), no suggested next steps, no invalid-value echoing for self-correction.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 77 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
api_request description lacks guidance on when to use noAiMode. The parameter description is technical ('return full response schema instead of AI-optimized') but doesn't explain the tradeoff or when an LLM should choose one over the other.
No documented limits on api_request response size. The noAiMode flag can 'increase context size significantly' but there's no stated maximum, pagination guidance, or overflow handling. An LLM may request full schemas for large datasets and exhaust context.