Loading ToolBench
MCP сервер для семантического поиска кода в информационных базах 1С. Индексирует выгрузку 1С XML, поддерживает CPU-only обработку и работу с несколькими ИБ.
This MCP server exposes 2 tools for searching 1C codebases. Both tools are explicitly registered with schemas and descriptions, but the definitions have significant gaps that limit LLM usability. Tool names follow the verb_noun pattern (search_code, list_ibs), which is good. However, descriptions are minimal (under 200 chars but generic), parameter descriptions lack actionable constraints, and output schemas are completely undocumented. The code returns TextContent with formatted markdown, but the LLM has no schema contract for what fields to expect or how to parse results. Error handling is basic (text error messages) with no recovery guidance. The server is STDIO-only, which is a hard cap at 50 for protocol readiness, but definition quality itself shows multiple pattern violations: missing output schema documentation, underdescribed parameters, no error classification, and no guidance on parameter constraints (e.g., what is a valid 'ib' name, what constitutes a good 'query').
Получить список доступных информационных баз 1С.
Поиск кода в информационных базах 1С. Поддерживает семантический поиск.
Output schemas are completely undocumented. search_code returns formatted text with numbered results, file paths, and scores, but the LLM has no contract for parsing this unstructured markdown. The _format_results function produces plain text, not structured JSON. This forces LLMs to infer structure from examples rather than relying on a declared schema.
Parameter descriptions lack actionable constraints. 'query' is described as 'Текст запроса для поиска (например: ...)' with examples in the description (text search examples), which violates the principle: do not put example values in descriptions, use enums and format constraints instead. 'ib' has no description of valid values or format. 'limit' lacks min/max bounds, unbounded integers let LLMs pass absurd values.
Error messages are plain text with no recovery guidance. When 'ib' is not found, the tool returns 'Ошибка: База X не найдена' with no suggestion of valid IB names or a recovery step (e.g., 'Call list_ibs() first to see available bases'). Error responses must tell the LLM what to do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
list_ibs returns a formatted text string ('Доступные базы:\n- **name**: title (Статус: status)') rather than structured data. The LLM cannot reliably extract IB names from this markdown to pass to search_code. This breaks the tool composition pattern, the output of list_ibs should include 'name' fields that downstream tools accept.
No documentation of what 'score' means in search results. The _format_results function shows 'Score: {r['score']:.3f}' but the LLM has no context: is 0.0 - 1.0 range? 0 - 100? Higher better or worse? Undocumented metrics make it impossible for LLMs to rank or filter results intelligently.
No input validation or user-fixable error messages. If an LLM passes an empty query or omits 'query' entirely, the tool returns generic error text. Parameter validation should be explicit and catch LLM mistakes early, returning guidance like: 'query is required and must be 1+ characters.'
Tool descriptions do not state what happens when results are paginated or truncated. search_code accepts 'limit' but does not explain what happens if more results exist (are they sorted by relevance? by file path?). The description does not mention that code_snippet is truncated at 500 chars.