MCP server for SuperJob — vacancy search, employers (Russia)
Server has 5 tools with complete schemas and descriptions in Russian. All tools follow verb_noun naming (search_*, get_*) and are READ_ONLY. However, descriptions are minimal (10-20 chars), parameter descriptions lack context about constraints and formats, and output schemas are not documented. No error handling guidance, no pagination metadata in responses, and no tool annotations. Schemas are present but sparse, parameters lack examples of valid ranges and formats beyond basic type info.
Справочник профессий/отраслей SuperJob (каталог).
Справочник городов SuperJob. Поиск по названию, фильтр по стране.
Полная информация о вакансии SuperJob по ID.
Поиск работодателей на SuperJob по названию и городу.
Поиск вакансий на SuperJob по ключевым словам, городу, зарплате.
Descriptions are too brief (10-20 chars). Rubric baseline is 194 chars avg; descriptions under 20 chars score ≤40. Examples: 'Поиск вакансий...' (11 chars), 'Полная информация...' (19 chars). LLMs cannot determine when/why to select tools from such minimal text.
Parameter descriptions lack actionable constraints. E.g., 'town' param says 'ID города (4=Москва, 14=СПб)' but does not explain what happens if an invalid town ID is passed, or how to discover valid IDs. 'count' has min/max in schema but no description of the constraint.
Output schemas are not documented. Tools return JSON.stringify(result) as plain text, but the structure of 'result' (fields, types, pagination) is not specified. LLMs cannot plan downstream calls or extract required IDs without knowing the response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
No error handling guidance. If an API call fails (e.g., invalid town ID, rate limit, timeout), the error is thrown as a raw exception. LLMs receive no actionable recovery hint (e.g., 'Try search_towns() first to find valid IDs').
No pagination metadata in responses. search_vacancies and search_employers accept 'count' and 'page' params but responses do not document total_count, has_more, or next_cursor. Without this, LLMs cannot determine if more results exist or how to fetch them.