Skip to main content
Glama
Sign In
mcp-1c-local-bridge

mcp-1c-local-bridge

by ntappw
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

execute

Runs 1C (BSL) code in an open 1C session and returns the value of the Результат variable. Changes roll back by default; set allow_write to save them.

Instructions

Выполняет фрагмент кода 1С (Выполнить) и возвращает значение переменной Результат.

На сервере код по умолчанию идёт в транзакции, которая после выполнения откатывается: изменения в базе
не сохраняются. Внешние эффекты откат не отменяет: файлы, HTTP, почта, запуск фоновых заданий, записи
журнала регистрации. Сообщения пользователю (Сообщить) с сервера возвращаются в ответе.

Выполнение занимает окно 1С пользователя: пока код работает, интерфейс его сеанса не отвечает. Долгую
операцию (обмен, массовую обработку) одним execute не запускай: если у неё есть экспортный метод общего
модуля конфигурации, запусти его фоновым заданием (ФоновыеЗадания.Выполнить) и опрашивай состояние задания
короткими командами. Фоновое задание идёт в своём сеансе, вне транзакции моста: его запись в базу не
откатывается и разрешением «Запись в базу» не ограничена - запускай его только с allow_write=true и с
согласия пользователя.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "execute"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesКод 1С: операторы без объявлений Процедура/Функция; результат присвойте переменной Результат.
sideNoserver - на сервере 1С; client - в модуле формы обработки на клиенте (нужно разрешение «Код на клиенте» на форме, транзакции и отката нет).server
formatNotable - таблицы и сводки для чтения, ссылки показаны представлениями; json - ответ как есть, с типами и UUID ссылок.json
sessionNoСеанс моста: идентификатор из sessions или часть строки соединения, имени конфигурации, пользователя. Не указан - единственный открытый сеанс.
timeoutNoСколько секунд ждать ответ. Команда, которую обработка не начала за это время, снимается; начатая выполняется дальше, её результат забирается инструментом result.
allow_writeNotrue - сохранить изменения, если на форме включено разрешение «Запись в базу»: по умолчанию код идёт в транзакции, которая фиксируется, только если он отработал без ошибок (см. transaction). Пока разрешение выключено, код всё равно выполнится с откатом, в ответе будет предупреждение.
transactionNoТолько для записи (allow_write=true). true - в транзакции: при ошибке изменения откатываются целиком. false - без транзакции моста: что код успел записать до ошибки, остаётся. false нужен долгим операциям (транзакция держит блокировки всё время выполнения) и коду, который сам управляет транзакциями или ждёт фоновые задания.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.0
    • changedInput schema / properties / allow_write / description
      Previous value: -"true - выполнить без отката транзакции, изменения сохранятся, если на форме включено разрешение «Запись в базу». Пока оно выключено, код всё равно выполнится с откатом, в ответе будет предупреждение."New value: +"true - сохранить изменения, если на форме включено разрешение «Запись в базу»: по умолчанию код идёт в транзакции, которая фиксируется, только если он отработал без ошибок (см. transaction). Пока разрешение выключено, код всё равно выполнится с откатом, в ответе будет предупреждение."
    • addedInput schema / properties / transaction
      Added value: +{
+  "default": true,
+  "description": "Только для записи (allow_write=true). true - в транзакции: при ошибке изменения откатываются целиком. false - без транзакции моста: что код успел записать до ошибки, остаётся. false нужен долгим операциям (транзакция держит блокировки всё время выполнения) и коду, который сам управляет транзакциями или ждёт фоновые задания.",
+  "title": "Transaction",
+  "type": "boolean"
+}
  2. First observedv1.1.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: default server execution runs in a transaction that is rolled back, external effects (files, HTTP, mail, background jobs, log records) are not rolled back, Сообщить messages come back in the response, and execution blocks the user's 1C session UI. It further discloses that background jobs run outside the bridge transaction, are not covered by the write permission, and must only be launched with allow_write=true and user consent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose, then transaction semantics, then the UI-blocking/background-job caveat, so structure is good. It is a long block of prose with dense sentences, but nearly every sentence carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a code-execution tool with write potential and no annotations, this is close to complete: safety model, side effects, blocking behavior, timeouts, and write-permission/consent prerequisites are all covered, and return values need not be explained because an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the interaction between allow_write, the transaction, and background jobs (which bypass both the rollback and the write permission). The remaining parameters (side, format, session, timeout) are largely left to their schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource (executes a 1C code fragment via Выполнить) and states the return value (the Результат variable). It does not explicitly distinguish itself from the sibling 'eval', which leaves a small ambiguity about which code-execution tool to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states concrete when-not guidance: do not run long operations (обмен, массовая обработка) in one execute, instead launch an exported common-module method as a background job and poll it with short commands. It also routes the agent to siblings: the 'result' tool for fetching output of a command that outlived its timeout requires, and consent requirements for write operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools