Loading ToolBench
MCP server for keyword research and SEO analysis using DataForSEO APIs, with support for database queries, AWS S3, and Google Gemini integration
Two tools with incomplete definitions. Both have basic descriptions (150-170 chars, acceptable) and parameter schemas, but critical gaps limit production readiness. `get_search_volume` has 3 well-described parameters with appropriate types and defaults. `getKeywordIdeas` has 8 parameters with mixed quality, some well-described (keywords, limit, location_code), others vague (filters, order_by lack actionable format guidance). Neither tool documents output schemas explicitly. No error handling guidance visible. No parameter validation constraints (e.g., max 20 keywords enforced, max 1000 limit capped). Tool naming uses verb_noun correctly but `getKeywordIdeas` violates camelCase convention vs snake_case (`get_search_volume`). No input validation described. Return object structure inferred from code but not formally documented for LLMs.
Fetches keyword ideas based on seed keywords using DataForSEO Keyword Ideas API. This endpoint provides keyword ideas based on the specified seed keywords. Results include search volume, competition, CPC, and related metrics.
Fetches keyword overview data for a given keyword using DataForSEO API.
Output schemas not documented. Neither tool explicitly documents what fields the LLM should expect in the response. `get_search_volume` returns a dict with 'keyword', 'search_volume', 'keyword_difficulty', 'main_intent', 'error', but this is inferred from code, not declared in tool metadata. `getKeywordIdeas` response structure completely undocumented in visible code. LLMs cannot plan downstream tool calls without knowing response format.
Tool naming inconsistency. `get_search_volume` uses snake_case; `getKeywordIdeas` uses camelCase. Violates naming convention, one should be `get_keyword_ideas`. LLM naming recall degrades with mixed conventions.
Parameter format constraints missing. `getKeywordIdeas` filters and order_by parameters accept arrays but lack actionable format descriptions. Example: '[["keyword_info.search_volume", ">", 100], "and", ["keyword_info.competition_level", "=", "LOW"]]' is buried in docstring, not in parameter schema description. LLMs cannot reliably construct valid filter syntax without explicit format guidance in the parameter description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
No input validation or error recovery guidance. Neither tool documents what happens if keyword is empty, location_code is invalid, language_code is unsupported, or API quota is exceeded. The get_search_volume code shows graceful handling ('No data available for this keyword') but this is not declared to the LLM in the tool description, so it cannot anticipate and handle the case. No recovery guide per pattern:recovery-guide.
Constraint violations not enforced or declared. getKeywordIdeas states 'max 20 keywords' and 'max 1000 limit' in the docstring description, but these are not reflected as JSON Schema constraints (maxItems, maximum). LLMs read descriptions, not schema, but formal constraints are clearer and machine-parseable.
Missing pagination guidance. getKeywordIdeas returns potentially large result sets but tool description does not discuss pagination, result limits, or how to handle > 1000 keyword ideas. Code suggests no built-in pagination; LLMs cannot retrieve large datasets without guidance on chunking strategy.
API credentials exposed in parameter flow. Code shows DATAFORSEO_API_KEY, DATAFORSEO_USERNAME, etc. being loaded from environment, correctly not exposed as tool parameters. However, no tool description mentions that credentials must be pre-configured, so LLMs may not understand why they cannot pass API keys as parameters. Add a note: 'This tool requires DataForSEO API credentials to be configured via DATAFORSEO_API_KEY environment variable.'