Loading ToolBench
MCP server for integrating with 1C Enterprise (1С Предприятие) ERP systems, providing tools for querying metadata, executing queries, analyzing configuration, and managing dumps
This server has moderate tool count (11) but significant quality gaps. Most tools have descriptions and readable names, but input schemas are either missing entirely (empty objects) or severely underspecified. The server defines tools like get_metadata_tree and get_configuration_info with {} input schemas, which cannot guide LLM parameter selection. Parameter descriptions are present in some cases (e.g., get_event_log lists enum values), but many tools lack depth. Output schemas are not documented anywhere in the visible code. Error handling exists (errorReporting=true) but recovery guidance is not evident. The test file (tool_registry_contract_test.go) validates tool registration counts but does not test schema quality or parameter validation. No tool annotations (readOnlyHint, destructiveHint) are present despite the tools being categorized as READ_ONLY or WRITE internally. Overall, this is a domain-specific tool set for 1C Enterprise introspection that sacrifices ease-of-use for raw API exposure.
Analyzes subsystems in 1C Enterprise configuration
Provides BSL (1C:Enterprise Script Language) syntax help
Executes a query against 1C Enterprise
Retrieves configuration information from 1C Enterprise
Retrieves event log entries from 1C Enterprise
Retrieves the structure of a form in 1C Enterprise
Fetches the metadata tree from 1C Enterprise
Gets the structure of a 1C object
Empty input schemas (JSON {}) on 3 tools: get_metadata_tree, get_configuration_info, reload_dump. These cannot guide LLM parameter selection or enforce constraints. LLMs have no way to know what inputs these tools accept.
No output schemas documented for ANY tool. The code does not define what structure these tools return (success format, error format, pagination, field names). LLMs cannot plan downstream tool chains or extract required fields without guessing.
Tool annotations missing. All tools marked READ_ONLY or WRITE internally, but no readOnlyHint or destructiveHint annotations visible in the MCP registration. Clients cannot infer tool safety or idempotency.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Reloads the dump index from disk
Searches code in the dump index
Validates a query against 1C Enterprise
Parameter descriptions are inconsistent. get_event_log has enum documentation ('Ошибка, Предупреждение, Примечание, Информация'), but most other tools have minimal descriptions like 'Type of the 1C object' or 'Query text to execute'. No format constraints (length, regex, ranges) documented.
No error handling guidance visible. errorReporting=true flag is set, but no examples show what error messages look like or how to guide LLM recovery (retryable vs user-fixable vs fatal).
Generic descriptions lack LLM-optimized context. 'Executes a query against 1C Enterprise' tells the LLM nothing about WHEN to use it (vs validate_query), what 'query' means (SQL? 1C-specific syntax?), or what constraints exist. Descriptions should include discovery hints.
Parameter naming ambiguity. 'object' in analyze_subsystems is vague, is it an object_name, object_type, object_id? The description says 'Object name for analysis' but the parameter is called 'object'. Should be 'object_name' to match parallel tools like get_object_structure.