Loading ToolBench
MCP server for Bukvarix API integration - keyword research and domain analysis
This server demonstrates solid tool definition practices with comprehensive parameter schemas, clear descriptions, and proper error handling guidance. All four tools have complete JSON Schema definitions with type constraints, enums, and range validations. Descriptions are detailed (200-600+ chars) and include usage examples, prerequisites, and error recovery paths. Tool names follow verb_noun conventions. However, there are gaps in output schema documentation, response field naming consistency, and lack of structured composition patterns across tools. The server would benefit from explicit return type documentation and clearer field-level parameter descriptions for some enum constraints.
Compare keywords between multiple domains. This tool compares keywords across 2-10 domains (free API limit: 10 domains). For 2 domains, you can specify comparison type (common, unique to first, unique to second). For 3+ domains, always returns common keywords (intersection).
Get keywords for a specific domain or subdomain. This tool retrieves keywords that the domain ranks for in search engines (Yandex or Google). You can specify domain or subdomain (without protocol). Cyrillic domains (.рф, .укр) are supported.
Search for keywords using a single query phrase. This tool searches Bukvarix database for keywords matching the query. Supports special syntax: - Wildcard: "строител* товары" (matches: строительные товары, товары для строительства) - Exclusions: "!строительные !товары" (excludes phrases containing these words) - Special characters (*, !, ~) are automatically percent-encoded
Search for keywords using multiple query phrases with optional exclusions. This tool performs extended search using a list of keywords. Each query phrase is processed separately. Free API allows up to 100 queries and 250 exclusions. Queries beyond limit are ignored.
Output schemas not explicitly documented in code. While descriptions mention response formats (JSON with 'data' array structure, field indices, truncation behavior), there is no formal JSON Schema object documenting the return type structure. LLMs cannot reliably extract what fields to expect from responses without seeing explicit output schema definitions.
Inconsistent parameter field naming conventions. The 'format' parameter uses lowercase enum values ('txt', 'json', 'csv', 'tsv') while 'report_type' uses snake_case enum values ('report', 'word_analysis'). Similarly, 'comparison_type' uses snake_case in enum but the parameter name is comparison_type. This inconsistency in naming could confuse agents when composing downstream calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Missing documentation of response field chaining. While the descriptions mention response structure (e.g., 'data' array with [keyword, words_count, chars_count, broad_frequency, exact_frequency] at specific indices), there is no explicit mapping of what IDs or references are returned that might chain to other tools. This is implicit in the descriptions but should be formally documented.
The 'region' parameter description in bukvarix_get_domain_keywords interpolates REGIONS object keys via template string (${Object.keys(REGIONS).join(", ")}), which may not be evaluated for the LLM. The description should contain the actual list of valid regions as a hardcoded enum list or reference, not a runtime interpolation. Similarly, compare_domains does not interpolate but lists regions inline, inconsistent.
No explicit documentation of result truncation thresholds. The description mentions 'Large responses (>25,000 chars) are truncated with a message' but does not specify what the truncation message says or how the agent should handle it. This is a critical behavior that should be explicitly specified so agents can plan for partial results.
Error handling descriptions list HTTP status codes (400, 401, 402, 429, 500, 503) but do not classify them as retryable, user-fixable, or fatal. An agent should know: 429 (rate limit) = retry with backoff, 401 (auth) = fatal/configuration error, 402 (limit exceeded) = user-fixable (reduce num parameter). This classification is missing.