Loading ToolBench
MCP server for каталогпо.рф — russian software catalog search
Three well-named, read-only tools with complete input schemas and strong descriptions (194 - 280 chars). All parameters have types and descriptions. Tool annotations (readOnlyHint, idempotentHint, openWorldHint) are correctly applied. Output schemas are not explicitly documented in the code, which is the primary gap. Error handling is basic (empty list on no match) but appropriate for read-only discovery tools. Naming follows verb_noun convention (search_, list_, get_). No security issues detected (no credentials, no state mutation).
Returns the curated list of highlighted Russian software products displayed on the каталогпо.рф homepage. Good starting point when the user does not yet know the exact category (e.g. 'покажи интересное из реестра'). Read-only, no parameters, idempotent. Content may change between calls as the catalog editors rotate highlights.
Paginated list of Russian software manufacturers. Each entry includes the vendor name, total product count and three preview products. Use to discover who is most active in a category, to cross-check if a given vendor is in the Минцифры registry, or to seed import-substitution research for a particular niche. Read-only HTTP call, idempotent for a given (page, limit) pair. Does not accept search filters — pair with search_russian_software when narrowing to a topic.
Full-text search across ~26 000 Russian software products aggregated by каталогпо.рф. Each result returns the product id, name, description and direct URL on the catalog. Descriptions commonly disclose ФСТЭК/ФСБ certification levels, compatibility with domestic OSes (Astra Linux, РЕД ОС, РОСА) and 152-ФЗ / 187-ФЗ compliance. Typical use cases: import-substitution (find a Russian analogue for foreign software), ФСТЭК-certified SIEM / DLP / antivirus discovery, vendor research. Read-only HTTP call to the catalog, no side effects, safe to retry. Empty/no-match queries return an empty list with a clear message.
Output schemas not documented. Tools return TextContent with formatted text, but the structure of the formatted response (fields, types, nesting) is not specified in tool definitions. LLMs cannot plan downstream operations or extract structured data reliably.
Response formatting is unstructured text. Tools call _format_search() and similar formatters that produce human-readable strings. For agent composition, structured JSON responses (array of objects with typed fields) would enable reliable field extraction and chaining.
No pagination metadata in search results. search_russian_software accepts a limit but does not return total_count, has_more, or next_offset. Agents cannot determine if results are truncated or plan multi-page retrieval.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
list_russian_manufacturers lacks required field in response. Description states 'Each entry includes vendor name, total product count and three preview products' but no output schema specifies these fields or their types. Agents cannot reliably extract product IDs for follow-up calls.
Error handling is minimal. Invalid query (empty string) returns a generic error message. No guidance on retryability, user-fixable vs. fatal errors, or recovery steps. Agents cannot distinguish transient failures from bad input.