MCP server for querying search traffic (SearchVisit) from SEO-MONITOR API. Supports JWT authentication via static token or email/password login with token refresh.
Single tool with basic structure but significant gaps in LLM-optimization and error handling. Tool name 'traffic' is generic and does not start with a clear action verb. Description exists but lacks key guidance on when/why to use this tool vs alternatives. Input schema is present and mostly well-typed, but parameter descriptions are minimal and lack constraints. Output is unstructured plain text rather than JSON, forcing LLMs to parse free-form strings. No error classification, recovery guidance, or actionable error messages. Server uses STDIO transport, capping protocol readiness at 50.
Получить трафик (поисковые визиты) за указанный месяц по проекту SEO-MONITOR. Вызывает GET /SearchVisit с time_group_by=month.
Tool name 'traffic' is generic and does not start with a clear action verb. Naming convention 'get_traffic', 'fetch_traffic', or 'list_traffic' would better convey intent and let LLMs infer semantics from the name alone before reading the description.
Tool description is in Russian and lacks LLM-optimization guidance. Does not explain WHEN to call this tool, WHAT it returns, or how it differs from other SEO monitoring approaches. Description should be 50-200 chars, actionable, and in the client's primary language.
Parameter descriptions are minimal or missing constraint information. 'Year (e.g., 2025)' is an example, not a constraint, LLMs may infer that only 2025 is valid. 'Month (1-12)' lacks description of consequences if invalid values are passed. No enum constraints declared for 'group_by' despite being restricted to 'type' or 'segment'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Output is unstructured plain-text string ('Трафик за 02/2025: 1234 визитов...'), not structured JSON. LLMs cannot reliably extract visit_count, min_date, or max_date for downstream reasoning or tool chaining. Tool should return {visits: int, min_date: string, max_date: string, message: string}.
Error messages are generic and non-actionable. Examples: 'Ошибка: задайте SEO_MONITOR_API_URL в окружении или .env.' (tells user to set env var, not relevant to agent), 'API вернул 401: ...' (no guidance on what to do next). Errors should classify as retryable/user-fixable/fatal and include recovery steps.
SEO_MONITOR_TOKEN is stored as static token in environment but never returned or exposed in responses, good for security. However, auth logic in auth_seo.py uses global state (_cached_access, _cached_refresh) which is not thread-safe and violates stateless request handling. Each request should carry its own auth context.
'devices' parameter has a default value ['DESKTOP', 'MOBILE', 'TABLET'] but description does not mention this default. LLMs cannot infer defaults from schema alone. Additionally, description should note that an empty array is not valid (would return zero traffic), so omitting the parameter is safer than passing [].
No idempotency guarantee declared. Calling traffic() twice with identical params should return the same cached result to prevent re-fetching from external API on retries. Tool should document whether repeated calls are safe.