An MCP server for accessing 1C database metadata and executing parameterized DaJet Script queries against registered SQL Server and PostgreSQL data sources
The DaJet MCP server exposes 10 tools for querying 1C database metadata and executing parameterized queries. Tool naming follows verb_noun convention (e.g., GetMetadata, ResetCache, ExecuteQuery), which is positive. However, the server exhibits significant definition quality gaps: (1) Descriptions are present but largely generic or non-English (8 of 10 tools have descriptions in Russian, which limits LLM comprehension in English-first deployments); (2) Parameter descriptions exist but are minimal and often in Russian; (3) Output schemas are not formally documented in the code, no inline schema definitions, enums, or field descriptions visible; (4) Error handling is present in the source (try-catch blocks, McpException throws) but error messages are minimal and sometimes in Russian; (5) Parameter validation is minimal, no visible constraints, ranges, or enum definitions. The codebase shows custom tooling infrastructure ([McpServerTool] attribute, DataTypeJsonConverter) but lacks the schema rigor needed for production agent interaction. Tools 1 - 9 operate on metadata and are read-only or reversible, which is good for safety. Tool 10 (ExecuteQuery) is a powerful but potentially dangerous tool with minimal schema documentation and no visible query validation beyond 'SELECT only'. Per-tool scoring reflects these gaps.
Executes a parameterized DaJet Script query to a registered 1C database data source. Returns an array of arbitrary JSON objects. Supports read-only SELECT queries only. Suitable for cross-database reports, and parameterized data access by 1C metadata object names.
Получает описание базы данных (конфигурации) по её имени
Получает описание структуры метаданных базы данных (конфигурации) по её имени
Получает список имён доступных баз данных
Получает описание структуры объекта метаданных базы данных (конфигурации) по его типу и имени
Получает описание структуры объекта метаданных базы данных (конфигурации) по его числовому коду
Получает список поддерживаемых типов объектов метаданных
Nine of ten tool descriptions are in Russian, blocking English-language LLMs from understanding tool purpose and selection criteria. Descriptions must be in English for broad agent interoperability.
No formal output schemas are documented. Complex return types (MdObject, Dictionary<string, List<string>>, InfoBase) exist but are not declared in MCP schema format. LLMs cannot plan downstream calls or extract required fields without documented output structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Сбрасывает кэш метаданных базы данных (конфигурации)
Получает имена объектов метаданных по их идентификаторю UUID для указанной базы данных (конфигурации)
Получает список полных имён объектов метаданных базы данных (конфигурации) по части имени (шаблону)
Parameter enums are not declared. Tools like GetMetadataObject accept 'type' as a free-form string, but valid values (Constant, Catalog, Document, etc.) exist and should be constrained via enum to prevent LLM hallucination.
ExecuteQuery tool lacks input validation and safety guards. 'script' parameter has no documented constraint to reject INSERT/UPDATE/DELETE. 'parameters' accepts arbitrary JSON with no schema. No mention of query timeouts, result row limits, or SQL injection prevention.
No result size limits or pagination guidance. SearchMetadataNames and ExecuteQuery can return unbounded lists, risking context window exhaustion. No visible limit parameter, next_cursor, or total_count in documented outputs.
Error messages are not LLM-actionable. Source code shows generic Russian error text ('Ошибка сброса кэша', 'База данных не найдена'). Errors should specify what went wrong and suggest corrective actions (e.g., 'Database not found. Try GetDatabaseNames() to list available databases.')