Skip to main content
Glama

1C Testpilot

MCP-сервер для работы AI-агентов с интерфейсом 1С:Предприятия. Позволяет агенту открывать формы, читать и изменять данные, работать с таблицами, записывать и воспроизводить сценарии действий.

Сервер подключается напрямую к локальному или удалённому клиенту тестирования 1С по его сетевому протоколу.

Возможности

  • Подключение к локальному или удалённому тест-клиенту по адресу и порту; порядок подключения определяется автоматически.

  • Запуск/останов тест-клиента 1С на компьютере MCP-сервера (файловая или серверная база, логин/пароль) с ожиданием готовности и авто-подключением — tc_session(action="launch_client"/"stop_client").

  • Навигация по дереву UI: активное окно → форма → элементы (по иерархическим ключам).

  • Чтение: значения полей, вид/класс/заголовки элементов, таблицы, области табличного документа.

  • Действия: ввод текста/HTML, клики, флажки, выбор из списков/меню, работа с таблицами и деревом, календарь, гиперссылки, навигация по строкам и окнам.

  • Запись и воспроизведение сценариев (uilog): агент выполняет шаги → получает XML-сценарий → воспроизводит его. Два режима записи (см. переменные окружения).

  • 10 инструментов по типам объектов клиента тестирования; конкретная операция выбирается параметром action (136 действий). Версионный гейтинг по целевой версии платформы.

Related MCP server: 1C MCP Server

Требования

  • Windows или Linux для MCP-сервера. Платформа 1С (напр. 8.3.27 или 8.5.1) нужна на компьютере тест-клиента.

  • Python 3.10+.

  • Тест-клиент 1С — либо поднимается действием tc_session(action="launch_client"), либо запускается заранее: 1cv8.exe ENTERPRISE /F"<база>" /TESTCLIENT -TPort <порт>

Установка

Установка из репозитория GitHub. Нужны Git и pipx.

pipx install git+https://github.com/ROCTUP/1c-testpilot.git
pipx ensurepath

После установки перезапустите терминал и MCP-клиент, чтобы они увидели команду 1c-testpilot. Зависимости устанавливаются автоматически в отдельное окружение.

Если репозиторий уже скачан, установите проект из его корневой папки:

pipx install .

Подключение к MCP-клиенту

Выберите способ подключения: stdio — MCP-клиент сам запускает 1C Testpilot; Streamable HTTP — вы запускаете сервер отдельно, а MCP-клиент подключается по URL.

Через stdio

Команда 1c-testpilot должна быть доступна в PATH MCP-клиента. Если клиент её не находит, укажите в command полный путь к исполняемому файлу.

Claude Desktop (документация). Откройте Settings → Developer → Edit Config и добавьте сервер в mcpServers:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json.

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json.

{
  "mcpServers": {
    "1c-testpilot": {
      "command": "1c-testpilot",
      "env": { "TC1C_TRANSPORT": "stdio" }
    }
  }
}

После изменения файла полностью перезапустите Claude Desktop.

Claude Code (документация):

claude mcp add --env TC1C_TRANSPORT=stdio --transport stdio --scope user 1c-testpilot -- 1c-testpilot

--scope user делает сервер доступным во всех проектах. Состояние подключения можно посмотреть командой /mcp внутри Claude Code.

Codex (документация). Добавьте в ~/.codex/config.toml:

[mcp_servers.1c-testpilot]
command = "1c-testpilot"
env = { TC1C_TRANSPORT = "stdio" }

Или добавьте сервер через CLI:

codex mcp add 1c-testpilot --env TC1C_TRANSPORT=stdio -- 1c-testpilot

Состояние подключения — /mcp в Codex. Для длительных операций, например запуска 1С, можно добавить tool_timeout_sec = 120 в секцию сервера; стандартный таймаут Codex — 60 секунд.

Без установки пакета можно указать напрямую: "command": "python", "args": ["<путь>/app/server.py"].

Через Streamable HTTP

Запустите 1C Testpilot в отдельном терминале.

Windows, PowerShell:

$env:TC1C_TRANSPORT = "streamable-http"
$env:TC1C_HTTP_HOST = "127.0.0.1"
$env:TC1C_HTTP_PORT = "6004"
$env:TC1C_HTTP_PATH = "/mcp"
1c-testpilot

Linux, Bash:

TC1C_TRANSPORT=streamable-http TC1C_HTTP_HOST=127.0.0.1 TC1C_HTTP_PORT=6004 TC1C_HTTP_PATH=/mcp 1c-testpilot

Пока сервер работает, он принимает MCP-подключения по адресу http://127.0.0.1:6004/mcp. Настройки TC1C_* задаются в окружении этого процесса сервера.

Claude Code:

claude mcp add --transport http --scope user 1c-testpilot http://127.0.0.1:6004/mcp

Эта настройка работает и в локальных сессиях вкладки Code приложения Claude Desktop: они используют MCP-конфигурацию Claude Code. Подключение к HTTP-серверу выполняется напрямую. Документация Claude Code Desktop.

Если сервер с таким именем уже добавлен через stdio, сначала удалите прежнюю запись командой claude mcp remove --scope user 1c-testpilot.

Codex — используйте URL в секции сервера в ~/.codex/config.toml:

[mcp_servers.1c-testpilot]
url = "http://127.0.0.1:6004/mcp"

При переходе со stdio замените прежние command, args и env на url. Для новой записи можно использовать CLI:

codex mcp add 1c-testpilot --url http://127.0.0.1:6004/mcp

Для подключения с другого компьютера задайте TC1C_HTTP_HOST равным сетевому IP компьютера с 1C Testpilot и укажите этот IP в URL клиента. Порт 6004 должен быть доступен из сети клиента. Встроенной HTTP-аутентификации в 1C Testpilot нет; доступ к серверу ограничивается вашей сетью или внешним прокси с аутентификацией и HTTPS.

Также поддерживается прежний транспорт SSE: TC1C_TRANSPORT=sse, адрес подключения http://127.0.0.1:6004/sse. У него стандартные пути /sse и /messages/; TC1C_HTTP_PATH применяется только к Streamable HTTP.

Подключение к клиенту тестирования 1С

Адрес, порт и версия платформы 1С передаются инструменту tc_session при выполнении действия connect. Эти параметры относятся к клиенту тестирования 1С и не задаются в конфигурации подключения MCP. Запуск клиента выполняется действием launch_client.

  • При локальном подключении host можно опустить: по умолчанию 127.0.0.1.

  • Удалённый клиент запустите с /TESTCLIENT -TPort <порт>; его порт должен быть доступен с компьютера MCP-сервера.

  • launch_client и stop_client работают на компьютере MCP-сервера. На Linux для запуска клиента нужен графический сеанс; для подключения к уже запущенному — не нужен.

  • Можно работать с несколькими базами или одной базой под разными пользователями. Подключение выбирается через connection_id, список — tc_session(action="list_connections").

Переменные окружения

Задаются в окружении процесса сервера (см. .env.example):

  • TC1C_CONNECTION_LIMIT — максимум зарегистрированных подключений, по умолчанию 16. Отключённый клиент, запущенный сервером, учитывается до stop_client. Лимит ссылок TC1C_REF_LIMIT применяется отдельно к каждому подключению.

  • TC1C_RECORD_MODE — режим записи сценариев: synth (по умолчанию — сервер собирает сценарий из вызовов инструментов, покрывая все действия агента) или native (журнал самого тест-клиента).

  • TC_PLATFORM_VERSION — целевая версия платформы (напр. 8.3.24.1548): действия, чей метод в этой версии отсутствует, не публикуются; версия используется в рукопожатии.

  • TC1C_RESPONSE_FORMAT — формат ответов: toon (по умолчанию) или json (режим совместимости).

  • TC1C_COMPACT_REFS — адресация элементов: id (по умолчанию), prefix или off. id работает с TOON и JSON; prefix сокращает адреса только в TOON. Прежние true и false принимаются как синонимы prefix и off.

  • TC1C_REF_LIMIT — максимум элементов в реестре одного подключения, по умолчанию 100000; положительное целое число. Ограничение действует во всех режимах адресации.

  • TC1C_VERIFY_TARGET — проверка существования объекта перед действием, true (по умолчанию) или false.

  • TC1C_READBACK — чтение состояния до и после действия, true (по умолчанию) или false.

Формат ответов

Формат ответов — TOON (компактный, по умолчанию) или JSON. Выбор: TC1C_RESPONSE_FORMAT.

Режим адресации элементов задаётся через TC1C_COMPACT_REFS:

  • id — короткие ссылки ref, передаваемые в действия без изменений; по умолчанию.

  • prefix — сокращённые адреса со словарями в ответе TOON; в JSON адреса полные.

  • off — полные адреса key и handle.

Инструменты

Сервер публикует 10 инструментов — по типам объектов клиента тестирования; операция выбирается параметром action, всего 136 действий. Список действий с методами 1С, применимыми типами и параметрами вынесен в отдельный документ: docs/TOOLS.md.

Запись и воспроизведение сценариев

tc_scenario(action="record_start") → выполнить действия → tc_scenario(action="record_finish") возвращает XML-сценарий (uilog) и lost_actions (действия, не попавшие в сценарий; при непустом списке сценарий неполный). Воспроизведение — tc_scenario(action="run_scenario", uilog=...). Режим записи — TC1C_RECORD_MODE.

Ограничения

  • Протокол закрытый и может отличаться между версиями платформы. Локальное подключение проверено на Windows с 8.3.27 и 8.5.1; удалённое — к Windows с 8.3.27 и к Ubuntu с 8.3.27. Способ подключения выбирается автоматически по ответу тест-клиента.

Available Tools

10 tools
tc_appA

Application-level state: active window, child objects, errors, dialogs, limits. Common operations for objects of this type live elsewhere: tc_field(action="is_visible"), tc_field(action="is_enabled"), tc_field(action="get_context_menu"). In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. Actions:

  • clear_file_dialog_result() Clear a previously set file-dialog result. (1C 8.3.25+)

  • get_active_window() Return the application's active window: {ref, class, title, platform_version} and sometimes form_name. title is the caption of the window's managed form — null only when the window has no form or the caption could not be read. form_name is the form's name in the configuration metadata ('Справочник.Контрагенты.Форма.ФормаСписка'), unrelated to name, which for a form is a GUID. form_name is read only when the window itself gave no caption and may be absent even then: its absence says nothing about the form. To read it explicitly call tc_app(action="get_child_objects") on the window ref. platform_version is the version of this connection; actions unavailable on it are refused with available_since. addressable=false means the window has no element address; this alone does not identify its type. When local recovery is unavailable, code=active_window_unavailable explains how to continue. A local print preview may report native=true and recovery="close_window": close it to return to the form before addressing form elements. (1C 8.3.3+)

  • get_child_objects(ref=null) List one level of child UI objects under the addressed parent. If its address is omitted, use the last observed active window, querying the client if no window has been observed. For a whole subtree in one call use tc_find(action="find_objects"). Returns an object with parent and children: [...]. Child metadata includes class and title; name and type may also be present. type names a recognized platform element kind (e.g. CheckBoxField or Pages), and may be null when no kind is known for that object. A ManagedForm row can also carry form_name, its name in configuration metadata (e.g. 'Справочник.Контрагенты.Форма.ФормаСписка'), useful when the title is empty. Always obtain object addresses from tool results. Address the parent with ref; children contain ref values. For a whole subtree, pass root_ref to tc_find(action="find_objects"). (1C 8.3.3+)

  • get_current_error() Get info about the session's last CLIENT error (none → null). error is the main description; details preserves additional text, including nested causes, module locations and stacks. This is not where an application refusal shows up: messages raised by the configuration ("field not filled in", "posting is not possible") arrive in tc_window(action="get_user_message_texts"). Read that one with care — it returns the ACCUMULATED messages of the session, so an old complaint is still there after a later action succeeded; clear it with tc_window(action="close_user_messages_panel") before the action you want to judge. (1C 8.3.3+)

  • get_max_action_time() Get the max action-execution time in seconds (set via tc_app(action="set_max_action_time"); None if unset).

  • get_parent(ref*) Get an element's parent in parent: [...]. The server resolves the parent's own address and returns it with the available object metadata. Address the element with ref; objects in parent contain their own ref values. (1C 8.3.24+)

  • get_performance(clear=False) Get accumulated session performance counters (calls, duration, sent, received). Set clear to also reset them, so the next read measures only what happened after this call. (1C 8.3.6+)

  • set_file_dialog_result(result=True, filename=null, filter_index=0) Predefine the next file dialog's result: result=True + filename to simulate picking a file, result=False to cancel. Pass a list of names to simulate a multi-file selection. filter_index selects which dialog filter is active (0-based). Replaces any previous pending answer. The next file dialog consumes it; clear_file_dialog_result cancels an unused answer. (1C 8.3.8+)

  • set_max_action_time(seconds*) Set the max action-execution time in seconds: how long a result-returning action may take before the call gives up (0 = wait indefinitely). Stored on the client (no network call) and applied to every subsequent command. connection_id selects the client. Passing ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in ref. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
refNo
clearNo
actionYes
resultNo
secondsNo
filenameNo
filter_indexNo
connection_idNo

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses version gating ('actions unavailable on it are refused with available_since'), null-return semantics for get_current_error, that user messages accumulate and must be cleared, local print-preview recovery, and that set_max_action_time is stored client-side with no network call. It stops short of stating auth requirements or rate limits, but no contradiction exists.

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?

A one-line purpose lead-in followed by per-action headings makes the long text navigable, and each action entry is front-loaded with its verb. The density is justified by a nine-action dispatcher, though several parenthetical version tags (e.g. '(1C 8.3.25+)') add length without aiding selection.

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?

With no output schema, the description must explain return values and does: get_active_window's {ref, class, title, platform_version}, get_child_objects' {parent, children:[...]}, get_parent's parent array, and get_current_error's error/details. For a complex multi-action tool with 8 params and zero schema coverage, nothing an agent needs to call it is missing.

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 description coverage is 0%, so the description must compensate and largely does: 'clear' resets counters, 'seconds' 0 = wait indefinitely, 'result=False' cancels, 'filename' accepts a list for multi-select, 'filter_index' is 0-based, and 'connection_id'/'ref' addressing rules are explained. The generic 'ref' and 'action' enum titles are also covered contextually, though not exhaustively for every parameter.

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

Purpose5/5

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

The description opens with a specific scope statement ('Application-level state: active window, child objects, errors, dialogs, limits') and then gives a distinct verb+resource definition for each of the nine actions. It also explicitly separates itself from siblings by name (tc_field, tc_find, tc_window), so an agent can route without opening any schema.

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 when to use alternatives with concrete calls: 'Common operations for objects of this type live elsewhere: tc_field(action="is_visible")...' and 'For a whole subtree in one call use tc_find(action="find_objects").' Prerequisites (connection_id required with several clients, ref expiry handling, clear-before-judge pattern) are spelled out.

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

tc_calendarA

Actions on a calendar field. Common operations for objects of this type live elsewhere: tc_field(action="is_visible"), tc_field(action="is_enabled"), tc_field(action="get_context_menu"), tc_app(action="get_parent"). In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. ok: true means the client accepted the command, not that anything changed — confirm an effect by reading the state back; target_check: present is not proof of one either. Where the address can be checked the response carries target_check: present, unknown (not checkable here) or off (checking disabled). target_hidden: true appears ONLY when the target exists and was NOT visible; it does NOT prove the absence of an effect — for tc_field(action="activate") invisibility is the normal precondition — it describes the ELEMENT itself and not an invisible container around it, and its absence says nothing. A wrong address is refused with an error only where the address can be checked: a read without a target marker cannot tell one from an empty answer, and tc_table(action="get_cell_text") on a table that does not exist returns text=null exactly as for an empty cell. Actions:

  • calendar_next_month(ref*) Move a calendar field to the next month. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • calendar_next_year(ref*) Move a calendar field to the next year. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • calendar_previous_month(ref*) Move a calendar field to the previous month. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • calendar_previous_year(ref*) Move a calendar field to the previous year. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • goto_date(ref*, year*, month*, day*) Go to a date (year, month, day) in a calendar field. Returns changed/value_before/value_after. connection_id selects the client. Passing ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in ref. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
dayNo
refNo
yearNo
monthNo
actionYes
connection_idNo

TDQS

A4.8/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 richly: ok:true only means the command was accepted, target_check present/unknown/off semantics, target_hidden meaning (exists but was not visible, no proof of absence, describes the element not a container), error behavior for unverifiable addresses, and ref expiry handling. It even flags that the four navigation actions cannot be verified at all.

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?

The verification preamble is front-loaded and earns its length, and each action carries a useful caveat plus the goto_date pointer. The same 'nothing readable changes, cannot be verified' sentence is repeated verbatim four times, which is mild waste but arguably justified since each action stands alone.

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 5-action dispatcher with 6 params, no annotations and no output schema, the definition covers purpose, per-action behavior, verification limits, return shape for goto_date (changed/value_before/value_after), and client selection. Nothing needed to invoke it correctly is missing.

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 0% across 6 params, so the description must compensate, and it does for the two non-obvious ones: ref (pass returned values unchanged, re-find on expiry) and connection_id (client selection rules). The trailing-* convention for required params is defined. year/month/day are only glossed as 'a date' but are self-evident.

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

Purpose5/5

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

The opening line names the resource (a calendar field) and the fact that this is a multi-action dispatcher, then explicitly routes the operations that belong to other tools (tc_field is_visible/is_enabled/get_context_menu, tc_app get_parent) elsewhere. An agent can distinguish this tool from every sibling without opening a schema.

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 which operations live in other tools and names them, and it explicitly redirects from the unverifiable month/year navigation actions to goto_date when the goal is to move the date. connection_id selection rules (auto when ref is passed, required when several clients and no ref) are spelled out with a pointer to tc_session(action="list_connections").

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

tc_docA

Actions on document fields and spreadsheet areas. Choose action. Common operations for objects of this type live elsewhere: tc_field(action="is_visible"), tc_field(action="is_enabled"), tc_field(action="get_context_menu"), tc_app(action="get_parent"). In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. ok: true means the client accepted the command, not that anything changed — confirm an effect by reading the state back; target_check: present is not proof of one either. Where the address can be checked the response carries target_check: present, unknown (not checkable here) or off (checking disabled). target_hidden: true appears ONLY when the target exists and was NOT visible; it does NOT prove the absence of an effect — for tc_field(action="activate") invisibility is the normal precondition — it describes the ELEMENT itself and not an invisible container around it, and its absence says nothing. A wrong address is refused with an error only where the address can be checked: a read without a target marker cannot tell one from an empty answer, and tc_table(action="get_cell_text") on a table that does not exist returns text=null exactly as for an empty cell. Actions:

  • begin_edit_current_area(ref*) Start editing the current spreadsheet-document area. Follow with input_text then end_edit_current_area to commit a new cell value. On a field that does NOT allow editing this does something else entirely: it runs the current cell's DETAILS — the platform's drill-down. It opens the object behind the cell, or a field chooser for a total, and choosing a row there gives the drill-down report. Set the current cell with set_current_area first.

  • click_formatted_doc_hyperlink(ref*, index*) Click a hyperlink in a formatted-document field by 0-based index (or by its text). On a document without links the platform answers the same and puts up its own error window, and tc_doc(action="get_formatted_string_hyperlinks") cannot be used to check first: for a formatted DOCUMENT it answers with an empty list even when the document does have a link (it lists links only for a formatted-string label). Judge by what the click was supposed to do. (1C 8.3.25+)

  • click_formatted_string_hyperlink(ref*, index*) Click a hyperlink in a formatted string by 0-based index (or by its text). ref may be a label field or a form decoration bearing the formatted string. (1C 8.3.13+)

  • click_html_hyperlink(ref*, index*) Click a hyperlink in an HTML-document field. The platform clicks the FIRST link whatever you pass: measured with three links and an index of 0, 1 and 2, and the same encoding the platform's own test manager sends. An index beyond the number of links is refused, so the argument is read — it just does not choose. Addressing by text does nothing at all here. (1C 8.3.25+)

  • end_edit_current_area(ref*, cancel=False) Finish editing the current spreadsheet-document area. Set cancel to discard the edit instead of committing it. Returns the cell address and its text before/after finishing; changed compares those values, including when an edit is cancelled.

  • get_area_text(ref*, area=null) Get the text of ONE spreadsheet-document area; omit area to read the current one. tc_doc(action="get_current_area_text") is the older form of this same call and answers identically; prefer this one. (1C 8.3.6+)

  • get_current_area_address(ref*) Get the address of the current spreadsheet-document area.

  • get_current_area_field(ref*) Get the field of the current spreadsheet-document area. (1C 8.3.2+)

  • get_current_area_text(ref*, area=null) Get the text of ONE spreadsheet-document area; omit area to read the current one. This is the older form of tc_doc(action="get_area_text"), which the platform deprecated in 8.3.6 in favour of that one; prefer get_area_text.

  • get_doc_area_horizontal_size(ref*) Get the horizontal size (max column number holding data) of a spreadsheet-document. (1C 8.3.13+)

  • get_doc_area_vertical_size(ref*) Get the vertical size (max row number holding data) of a spreadsheet-document. (1C 8.3.13+)

  • get_formatted_string_hyperlinks(ref*) Get a formatted string's hyperlink presentations. (1C 8.3.25+)

  • get_html(ref*) Read the HTML of a formatted/HTML-document field. After the form has put up a menu or a modal choice list, the platform stops returning this field's content until it is written again — an empty answer right after such a window does not mean the field is empty. (1C 8.3.8+)

  • included_in_merged_area(ref*, address*) Return the address of the merged area containing the cell (e.g. 'R1C1'), or None if the cell is not part of a merged area. A null answer is ambiguous in one more way: it also comes back when the document has no such cell or no area by that name — the platform does not distinguish the two, and neither can this action. Only the FORM of the address is checked here (cell, range, area name, intersection); whether it exists is up to the document. (1C 8.3.25+)

  • input_html(ref*, html*, attachments=null) Set HTML/text into a formatted-document field. attachments maps an image name used in the HTML (e.g. -> "p1") to that image as a base64 string; names must be identifiers (no dots). (1C 8.3.8+)

  • read_document(ref*, start_address=null, max_cells=1000) Read nonempty spreadsheet cells as rows with cell addresses and merged-cell spans. Uses the document's data bounds. If complete=false, pass next_address as start_address to continue. max_cells limits positions scanned per call (1–10000).

  • set_area_text(ref*, address*, text*) Set a spreadsheet cell's text by address, e.g. R2C1. Selects the cell, starts and finishes editing, then reads the result. Empty text clears it. Returns verified, changed and value_before/value_after. Numeric formatting can return verified=null with verification=numeric_equivalent. Requires an editable document.

  • set_current_area(ref*, address*) Set the current area of a spreadsheet-document field (e.g. 'R1C1').

  • text_within_area_bounds(ref*, area=null) Whether the text in a spreadsheet-document area fits within its bounds (True) or is clipped to '#####' (False). Pass area (e.g. 'R1C1'); omit to check the current cell. (1C 8.3.25+)

  • write_content_to_file(ref*, filename=null, file_format=null, filter_index=null, save_as=null) Save an HTML, formatted, spreadsheet or text document field. PDF fields do not support this action. With filename, Save As is used even for a previously saved document; this call replaces pending file-dialog answers and clears its answer afterwards. For spreadsheets choose file_format: mxl, html, pdf, xls, xlsx, ods or docx. Example: filename="C:/exports/report.xlsx", file_format="xlsx". The extension alone does not select a format. Alternatively filter_index selects a dialog's file type (0-based); do not combine it with file_format. Without either option the dialog's first file type is selected. Without filename, saves under the current name unless save_as=true. If a dialog can appear, prepare it before EACH call using tc_app(action="set_file_dialog_result"). ok confirms that the save request was accepted, not that a file has finished writing. (1C 8.3.8+) connection_id selects the client. Passing ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in ref. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
refNo
areaNo
htmlNo
textNo
indexNo
actionYes
cancelNo
addressNo
save_asNo
filenameNo
max_cellsNo
attachmentsNo
file_formatNo
filter_indexNo
connection_idNo
start_addressNo

TDQS

A4.1/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 discharges it unusually well: `ok: true` means acceptance not effect; `target_check` values (present/unknown/off); `target_hidden` proves neither presence nor absence of an effect; get_html silently returns empty after a modal; click_html_hyperlink always clicks the first link regardless of index; included_in_merged_area returns null both for 'no cell' and 'not merged'. These are exactly the traps an agent needs disclosed.

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

Conciseness3/5

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

The overall shape is sound — purpose, sibling routing, cross-cutting caveats, then a scannable per-action list — and some length is unavoidable for 20 actions. But the opening caveat block is dense and repetitive (effect-vs-acceptance restated for write_content_to_file), and anecdotes such as the three-link measurement and the tc_table get_cell_text analogy spend words on justification rather than instruction.

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

Completeness4/5

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

For a 20-action, 16-parameter dispatcher with no annotations and no output schema, the definition covers connection selection, ref reuse and expiry, pagination via next_address/complete, return fields for set_area_text and end_edit_current_area, and per-action preconditions. A few read actions (get_current_area_address, get_current_area_field, get_doc_area_*_size) still leave their return shape to inference.

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 description coverage is 0%, so the description must compensate, and it largely does: signatures mark required `ref*`, define `attachments` as a name→base64 map with identifier-only names, enumerate `file_format` (mxl/html/pdf/xls/xlsx/ods/docx), bound `max_cells` (1–10000), explain `filter_index` as 0-based and mutually exclusive with file_format, and clarify `connection_id` selection semantics. Gaps remain for `address`, `text`, `area`, and `index` beyond scattered examples like 'R2C1'.

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?

States a clear verb+resource: 'Actions on document fields and spreadsheet areas' with an explicit 'Choose `action`' dispatcher instruction, and the 20-action list makes the scope concrete. It differentiates itself from siblings by naming tc_field and tc_app as the home for common operations 'for objects of this type', though the top-line summary itself is broad and relies on the action list to become specific.

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

Usage Guidelines4/5

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

It routes the agent away from this tool for common operations (tc_field(action="is_visible"), tc_app(action="get_parent")) and gives explicit preference guidance between overlapping actions ('prefer get_area_text' over the deprecated get_current_area_text). It also flags version gates (1C 8.3.x+) that constrain when an action is usable, but never states an overall when-not-to-use-this-tool condition.

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

tc_fieldA

Actions on a form field, button, group or element addition. Choose action. Common operations for objects of this type live elsewhere: tc_app(action="get_parent"). In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. ok: true means the client accepted the command, not that anything changed — confirm an effect by reading the state back; target_check: present is not proof of one either. Where the address can be checked the response carries target_check: present, unknown (not checkable here) or off (checking disabled). target_hidden: true appears ONLY when the target exists and was NOT visible; it does NOT prove the absence of an effect — for tc_field(action="activate") invisibility is the normal precondition — it describes the ELEMENT itself and not an invisible container around it, and its absence says nothing. A wrong address is refused with an error only where the address can be checked: a read without a target marker cannot tell one from an empty answer, and tc_table(action="get_cell_text") on a table that does not exist returns text=null exactly as for an empty cell. Actions:

  • activate(ref*) Give a form element the focus — this is how you switch to a page or make a table column the current cell; a click does neither. It also commits text left uncommitted by tc_field(action="input_text"), but only when you activate a DIFFERENT focusable element: the field you typed into already has the focus. To let the form choose the next focus target, use tc_form(action="goto_next_element") on the form. Reports no changed — verify with tc_field(action="get_text"), tc_field(action="get_current_page"), tc_form(action="get_current_element") or tc_table(action="get_current_item").

  • cancel_edit(ref*) Cancel editing an input field. (1C 8.3.6+)

  • choose_from_drop_list(ref*, value*) Pick a value from a field's open drop-down list by its display text (e.g. a colour name) or by its 0-based index in the list. The value is written at once — no focus change is needed. changed may come back null here even when the value did change: with the list open the value cannot be read. Read the field with tc_field(action="get_text") to confirm. (1C 8.3.6+)

  • clear(ref*) Clear an input field's value.

  • click(ref*) Click a form element (button, cell, etc.). A click PRESSES the element; it does not make it current — clicking a page does not switch to it and clicking a cell does not make it the current cell. Use tc_field(action="activate") for that.

  • click_view_status_item(ref*, index*) Click a view-status item by 0-based index (or by its text). Nothing here proves the item was there: the platform answers the same when the form has no view-status line at all, and reading the texts first does not settle it either — that read comes back empty even while a search or filter is active. Judge by the list itself: read the rows before and after. (1C 8.3.16+)

  • close_drop_list(ref*) Close a field's drop-down list. Verify with tc_field(action="drop_list_is_open"). (1C 8.3.6+)

  • create(ref*) Create a new object from a reference field: opens the new object's form, as the field's '+' does. The field must have the FOCUS first — call tc_field(action="activate") on it, otherwise the command is accepted and nothing opens. Verify by reading the active window. (1C 8.3.6+)

  • current_check(ref*) Whether a form BUTTON is pressed, or shows a check mark next to it. Only buttons answer meaningfully: anything else — a checkbox field, a page, a table — always reports false, which means 'not applicable', not 'switched off'. Read a checkbox with tc_field(action="get_text") ('Да'/'Нет') and the active page with tc_field(action="get_current_page"). (1C 8.3.16+)

  • current_mode_is_edit(ref*) Whether a table is currently in edit mode. (1C 8.3.3+)

  • current_opened(ref*) Whether a form group is currently open. (1C 8.3.16+)

  • decrease_value(ref*) Decrement a numeric (spinner) field. A track bar does NOT take this — move it with tc_field(action="goto_value") in percent. When the value does not move, applicable: false in the answer means the method does not fit this kind of field.

  • delete_view_status_item(ref*, index*) Delete a view-status item by 0-based index (or by its text) — this is how a filter or a search chip is dropped. Nothing here proves the item was there: the platform answers the same when the form has no view-status line, and reading the texts first does not settle it either. Judge by the list itself: read the rows before and after. (1C 8.3.16+)

  • drop_list_is_open(ref*) Whether a field's drop-down list is open. (1C 8.3.6+)

  • execute_choice_from_choice_list(ref*, value*) Pick from a field's choice list by its display text or by its 0-based index. Reports changed/value_before/value_after — the field's value read before and after, same as tc_field(action="choose_from_drop_list").

  • get_choice_list(ref*) Get a field's choice list. Read it while the drop-down list is OPEN: with the list closed the answer is empty and status is 'unknown', which is normal, not an error. The answer describes the list that is currently OPEN, not the element you addressed — with one field list open, any other field ref returns that same list with status='ok'. Open the list on the field you are asking about (tc_field(action="open_drop_list")) and read it immediately. 'items' holds {presentation, text} per entry; 'presentations' is just their texts, which is exactly what tc_field(action="choose_from_drop_list") accepts. (1C 8.3.12+)

  • get_command_bar(ref*) Get an element's own command panel object, if it has one. This is NOT the list of buttons: the panel is a container, and its buttons are read with a separate tc_app(action="get_child_objects") on the returned ref. An empty result means the element has no command panel of its own — a list table is the usual case, its buttons live in a form group next to it. (1C 8.3.3+)

  • get_context_menu(ref*) Get an element's context menu. The platform returns the menu as a form GROUP, not as a list of commands: 'menu' holds that group, and its items are read with a separate tc_app(action="get_child_objects") on the group's ref. (1C 8.3.3+)

  • get_current_page(ref*) Get the current page of a page group. To switch pages use tc_field(action="activate"): a click on a page does not switch to it. tc_field(action="current_check") is useless here — pages always report checked=false. (1C 8.3.6+)

  • get_data_presentation(ref*) Get an element's data presentation. Form fields only — not form decorations, and on a table the answer is always null. An empty input field returns "". presentation is null when no value was available; that is not proof that the field has no presentation.

  • get_edit_text(ref*) Read an input field's edit buffer — what is being typed, which is not necessarily what the form holds. get_data_presentation reads the accepted value; get_text reads displayed text. An empty input buffer returns ""; null means unavailable. (1C 8.3.3+)

  • get_linked_window(ref*) Get the linked window of a command-interface button. An empty answer means the button has no linked window — but only when target_check says the button itself is there; a wrong ref answers empty too, and the check is what tells the two apart. (1C 8.3.6+)

  • get_state_presentation(ref*) Read a form field's state presentation. An unavailable value is explained in the answer; null does not confirm that the field has no state presentation. (1C 8.3.16+)

  • get_text(ref*) Read displayed text (checkbox text follows the client language). An empty input field returns "". For an edit buffer use get_edit_text. If text is unavailable, the answer explains the limitation and suggests another reading action where applicable. null does not confirm an empty field. (1C 8.3.12+)

  • get_tooltip(ref*) Read an element's tooltip text (empty → None). (1C 8.3.3+)

  • get_view_status_item_texts(ref*) Get the view-status item texts of a form-element addition → list of strings. Do not use it to tell whether a filter or search is active: with a list narrowed down to one row by search the platform still answers with an empty collection. Check the effect by reading the rows. (1C 8.3.16+)

  • goto_value(ref*, percent*) Move a TRACK BAR to a value in PERCENT (0..100). This is a track bar method: on any other kind of field the command is accepted and nothing moves, and the answer then carries applicable: false. A spinner is stepped with increase_value/decrease_value instead. Returns changed/value_before/value_after. (1C 8.3.6+)

  • increase_value(ref*) Increment a numeric (spinner) field. A track bar does NOT take this — move it with tc_field(action="goto_value") in percent. When the value does not move, applicable: false in the answer means the method does not fit this kind of field.

  • input_text(ref*, text*, finish=True) Enter text. Ordinary form input fields finish automatically: the owning form moves focus once to its next element, then the accepted value is checked. finish=false leaves the editing buffer active, for example before choosing a reference suggestion or cancelling. Empty text clears the value directly. Reference input can still need a matching value. committed=true confirms the accepted text; false means pending; null means unverified. edit_finished reports whether focus left the ordinary field. Numeric formatting can produce verification=numeric_equivalent with committed=null. changed compares displayed text. These flags do not mean the record was saved. Table cells use tc_table(action="set_cell_text"). Text documents finish by activating another element with tc_field(action="activate"); spreadsheet cells use tc_doc(action="end_edit_current_area").

  • is_enabled(ref*) Whether an element is currently enabled. (1C 8.3.3+)

  • is_readonly(ref*) Whether an element is currently read-only — that is the element's own read-only property. Two other things look the same and are NOT this: an element switched off entirely (read that with tc_field(action="is_enabled")), and a spreadsheet-document field shown in view mode, which neither read reflects — there, tc_doc(action="begin_edit_current_area") runs the cell's details instead of editing. (1C 8.3.3+)

  • is_visible(ref*) Whether an element is currently visible. Returns an error instead of visible=false when there is no object at ref: for this read the protocol does report a missing target, so a mistyped address cannot pass for a hidden element. On the pages of a page group this does NOT tell you which page is on screen — several pages report visible=true at once; use tc_field(action="get_current_page") for that. (1C 8.3.3+)

  • open_drop_list(ref*) Open the drop-down list of a reference/enum field (call before choose_from_drop_list). (1C 8.3.6+)

  • open_field(ref*) Open a reference field's value (F4 / follow the link).

  • select_option(ref*, value*) Pick a radio-button option by its display text or by its 0-based index.

  • set_check(ref*) Toggle a checkbox field. Inside a table this acts on the column that is the CURRENT cell, so make the target column current first — tc_field(action="activate") on the column element does that; a click on the cell does not.

  • start_choosing(ref*) Open a reference field's choice form. Handles focus and table-cell editing. Returns opened and the active window; use that window to continue choosing.

  • start_choosing_from_choice_list(ref*) Start choosing from a field's choice list.

  • title_is_shown(ref*) Whether an element's title is shown. (1C 8.3.25+)

  • wait_for_drop_list_generation(ref*, timeout=60) Wait up to timeout seconds for a drop-down list to be generated. Returns generated=True if a list appeared within the timeout, else False. The answer is not tied to the element you addressed — it can come back true before this field's list is open at all, the same way get_choice_list describes. Open the list on the field you care about first (tc_field(action="open_drop_list")) and read it right after. (1C 8.3.4+) connection_id selects the client. Passing ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in ref. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
refNo
textNo
indexNo
valueNo
actionYes
finishNo
percentNo
timeoutNo
connection_idNo

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description bears the full burden and discharges it: `ok:true` explicitly does not mean the state changed, `target_check`/`target_hidden` semantics are spelled out, `changed`/`committed`/`applicable` flags are explained, and version requirements (1C 8.3.x+) are attached per action. It even warns about misleading null/empty answers and warns that editing flags do not mean a record was saved.

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?

The general caveats are correctly front-loaded before the action list, and each action entry is a tight paragraph. It is long, but the 40-action surface justifies most of it; some redundancy remains (the view-status item ambiguity and the target_check/target_hidden caveats are restated across several actions).

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 40-action dispatch tool with no output schema and 0% schema description coverage, the definition supplies the action catalog, per-action verification guidance, cross-tool routing, and connection resolution rules. Nothing an agent needs to select and invoke an action correctly appears to be missing.

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

Parameters5/5

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

Schema coverage is 0% (titles only), so the description must compensate and does: ref semantics ("Pass reference values returned by the tools unchanged"), index (0-based), value (display text or 0-based index), percent (0..100 for track bars), timeout (seconds, default 60), finish (false leaves the edit buffer active), and connection_id (auto-derived from ref, else required with multiple clients). Every parameter receives meaning beyond its bare name.

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 umbrella sentence "Actions on a form field, button, group or element addition. Choose `action`." names the resource and the dispatch mechanism, and the per-action entries give specific verbs (activate, click, goto_value, input_text). It actively distinguishes itself from siblings by pointing to tc_app, tc_form, tc_table and tc_doc for related work. The only weakness is that the top-level purpose is a catch-all, but the action catalog makes its scope unmistakable.

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?

Nearly every action documents when to use it versus an alternative: activate vs click ("a click does neither"), goto_value vs increase_value/decrease_value for track bars vs spinners, get_edit_text vs get_text vs get_data_presentation, and set_check requiring the column be made current via activate first. It also routes callers to sibling tools (tc_form(action="goto_next_element"), tc_table(action="set_cell_text"), tc_doc(action="begin_edit_current_area")). This is explicit when/how/alternative guidance throughout.

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

tc_findA

Search the UI tree for objects. In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. Actions:

  • find_object(name=null, cls=null, type=null, root_ref=null, title=null, timeout=0) Find the first object matching the criteria (parameters as in tc_find(action="find_objects")). When nothing matched, the answer carries the same filter diagnostics as tc_find(action="find_objects"). (1C 8.3.3+)

  • find_objects(name=null, cls=null, type=null, root_ref=null, title=null, timeout=0) Find all objects in the UI tree matching the criteria. name and title take the wildcards * and ?; cls is the class and type is the platform's element kind (both as reported by tc_app(action="get_child_objects"), e.g. CheckBoxField or Popup); root_ref is where to start (default: the active window); timeout keeps retrying for that many seconds while nothing matches (0 = a single pass). An empty result is not an error, so ok stays true. When nothing matched and a cls or type was given, the answer also says whether the server knows that filter and what was actually present, so a misspelling is distinguishable from an object that never appeared. (1C 8.3.3+)

  • wait_for_object_displayed(name=null, cls=null, type=null, title=null, timeout=60) Poll the UI tree until an object matching the criteria appears, up to timeout seconds. Returns the object, or ok=False on timeout. Criteria as in tc_find(action="find_objects"). On timeout the answer says whether a cls was seen at all and lists the classes that were actually present, so a misspelled class name is distinguishable from an object that never appeared. (1C 8.3.3+) connection_id selects the client. Passing root_ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in root_ref. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
clsNo
nameNo
typeNo
titleNo
actionYes
timeoutNo
root_refNo
connection_idNo

TDQS

A4/5.0
Behavior4/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 well: it discloses that empty results are not errors (ok stays true), that timeout causes ok=False on wait, how retry/timeout semantics work, and what diagnostics accompany a miss (known-filter check, actually-present classes). It omits any note on side effects or rate limits, so a 4 rather than 5.

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?

Front-loads the purpose and the required-parameter convention, then organizes per-action stanzas. The repeated '(parameters as in ...)' cross-references and signature blocks add length, but most sentences carry real information rather than filler.

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

Completeness4/5

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

For an 8-parameter tool with no annotations and no output schema, the description is thorough: it covers every action, field semantics, the connection requirement, and the reference-lifetime caveat ('pass reference values unchanged... find the element again'). The only gap is a slightly thin distinction between cls and type.

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 description coverage is 0%, so the description must compensate, and it largely does: it documents name/cls/type/root_ref/title/timeout/connection_id and explains wildcard support (* and ?), root_ref default (active window), and timeout semantics. A few fields (notably 'type' vs 'cls') are explained somewhat indirectly, leaving minor ambiguity.

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?

States a specific verb and resource ('Search the UI tree for objects') and enumerates three distinct actions with signatures. An agent can tell what each action returns (first match, all matches, polling result). It does not explicitly differentiate itself from the tc_app/tc_window siblings, which keeps it just shy of a 5.

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

Usage Guidelines4/5

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

Gives clear per-action intent: find_object for the first match, find_objects for all matches, wait_for_object_displayed for polling until appearance. It also routes to tc_session(action="list_connections") for connection selection and explains the root_ref-vs-connection_id choice. No explicit 'when not to use' or named alternative tool, so not a 5.

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

tc_formA

Actions on the managed form itself, including navigation between form elements and reading the focused element. Choose action. Common operations for objects of this type live elsewhere: tc_field(action="is_visible"), tc_field(action="is_enabled"), tc_field(action="get_context_menu"), tc_app(action="get_parent"). In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. ok: true means the client accepted the command, not that anything changed — confirm an effect by reading the state back; target_check: present is not proof of one either. Where the address can be checked the response carries target_check: present, unknown (not checkable here) or off (checking disabled). target_hidden: true appears ONLY when the target exists and was NOT visible; it does NOT prove the absence of an effect — for tc_field(action="activate") invisibility is the normal precondition — it describes the ELEMENT itself and not an invisible container around it, and its absence says nothing. A wrong address is refused with an error only where the address can be checked: a read without a target marker cannot tell one from an empty answer, and tc_table(action="get_cell_text") on a table that does not exist returns text=null exactly as for an empty cell. Actions:

  • current_modified(ref*) Whether a form has been modified. (1C 8.3.3+)

  • execute_choice_from_list(ref*, index*) Pick an item from a modal choice list by 0-based index or display text. Not a field's drop-down (use tc_field(action="choose_from_drop_list")). ref: the form (ManagedForm), not a field. (1C 8.3.8+)

  • execute_choice_from_menu(ref*, index*) Pick an item from an OPEN menu by 0-based index or display text; nested submenus are not supported. This works for a menu the form put up, and for the menu a spreadsheet document raises over a cell that has DETAILS — address the form or the field, either reaches the menu that is open. It selects from a menu that is ALREADY open: if none is, nothing happens. On a spreadsheet-document field this needs platform 8.3.25 or newer. (1C 8.3.8+)

  • find_default_button(ref*) Find the form's default button. ref is the form's ref. (1C 8.3.3+)

  • get_current_element(ref*) Get the managed form's focused element as item: [{ref}]. ref: the form (ManagedForm). The platform can return no current element after navigating out of its fields.

  • goto_next_element(ref*) Move focus to the next element in the managed form's tab order. ref: the form (ManagedForm). This can finish the current field's pending input; read the field's data presentation to verify acceptance. Reference fields may still require choosing a value.

  • goto_previous_element(ref*) Move focus to the previous element in the managed form's tab order. ref: the form (ManagedForm). This can finish the current field's pending input; read the field's data presentation to verify acceptance.

  • wait_for_closing(window_title=null, timeout=60) Wait until a window closes, up to timeout seconds. Without window_title it watches the window that is active AT THE MOMENT OF THE CALL, so it only makes sense BEFORE the action that closes something; called after tc_window(action="close_window") it is already watching the next window and will time out while reporting the window is still open. After a close, pass window_title — the title is taken from the window's managed form, and if it cannot be determined the call says so instead of claiming the window closed. (1C 8.3.3+) connection_id selects the client. Passing ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in ref. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
refNo
indexNo
actionYes
timeoutNo
window_titleNo
connection_idNo

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so richly: it explains that ok:true only means the command was accepted, that target_check (present/unknown/off) and target_hidden do not prove an effect, how wrong addresses are refused, and the specific caveat that calling wait_for_closing after tc_window(action="close_window") will time out. This is well beyond what a bare mutation/read annotation would convey.

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?

Long, but front-loaded with purpose, then sibling routing, then a global-semantics block, then per-action signatures with annotations. Nearly every sentence earns its place given 8 actions, 6 params, 0% schema coverage and zero annotation help; only the safety preamble is slightly repetitive.

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?

With no output schema and no annotations, the description supplies the burden-covering detail an agent needs: state-verification semantics, address-check behavior, per-action preconditions and platform-version notes. Nothing critical for correct invocation appears missing.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and it does: it defines the `*` required-marker convention, clarifies ref is the form (ManagedForm) and not a field, index is 0-based (or display text), timeout is in seconds, window_title semantics for wait_for_closing, and connection_id client selection plus auto-selection when ref is passed. It adds substantial meaning the flat schema cannot.

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

Purpose5/5

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

States a specific verb+resource ('Actions on the managed form itself, including navigation between form elements and reading the focused element') and immediately routes operations that belong to siblings elsewhere (tc_field, tc_app). An agent can distinguish tc_form from tc_field without opening either schema.

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?

Explicitly says which operations live on other tools ('tc_field(action="is_visible")', 'tc_app(action="get_parent")') and gives per-action conditions (e.g. execute_choice_from_list is 'Not a field's drop-down', execute_choice_from_menu requires an already-open menu, wait_for_closing must precede the closing action). Alternatives and exclusions are named, not inferred.

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

tc_scenarioA

Record and replay UI scenarios. In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. Actions:

  • record_cancel() Cancel user-actions recording (discard the scenario). (1C 8.3.2+)

  • record_finish(path=null) Stop recording and return the scenario XML in 'uilog', or write it to path, resolved against the SERVER working directory and echoed back absolute. If the file cannot be written the answer carries ok=false, the path, the reason AND the scenario in 'uilog' — recording is already stopped, so a second call will not give it back. lost_actions: actions that could not be captured, so the scenario is incomplete for replay. no_effect: calls whose value came back unchanged — a hint to check, not a verdict, and it numbers CALLS, not steps of the XML. observed/not_observed count the calls whose result could and could not be read back; readback/scope say whether reading back was on at all and how wide it reached. An empty no_effect with zero observed means nothing was checked. (1C 8.3.2+)

  • record_pause() Pause user-actions recording: actions performed until tc_scenario(action="record_resume") stay out of the scenario. (1C 8.3.2+)

  • record_resume() Resume user-actions recording. (1C 8.3.2+)

  • record_start() Start recording a scenario (uilog) that tc_scenario(action="run_scenario") can replay later. Perform the real, effect-producing actions between start and tc_scenario(action="record_finish"), then read the scenario from finish. (1C 8.3.2+)

  • run_scenario(uilog=null, path=null) Replay a recorded uilog scenario on the current form. Give the XML in uilog or a path to a file with it. Steps that could not be replayed are listed in unsupported. total counts every step in the scenario; played counts the ones actually attempted, REGARDLESS of how they went, so a failed step is still counted. Neither is a count of effects: ok says every attempted step was accepted, and the effect of a step is in steps[].changed, the same contract as when you call the action directly. connection_id selects the client. With several clients, connection_id is required. Use tc_session(action="list_connections").

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo
uilogNo
actionYes
connection_idNo

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral burden and does so substantially: it explains file path resolution, the error handling for record_finish, the lost_actions and no_effect fields, readback scope, and the replay step counting nuances (played vs ok, changed). This is far more than typical. A 4 is appropriate because it is candid about failure modes and semantics, though it does not cover authentication or concurrency constraints.

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

Conciseness3/5

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

The description is dense and front-loaded with the purpose, but it is long and some sentences are nested with complex clauses. The per-action documentation is necessary but could be more structured. It is not bloated, but it could be more scannable.

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

Completeness4/5

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

Given the complexity (multi-action tool, 4 parameters, no output schema), the description is largely complete. It explains the workflow, error conditions, return value nuances, and connection handling. It does not describe the exact shape of the return object (e.g., whether it returns a dict with 'ok', 'uilog', etc.), but it references those fields by name. The lack of an output schema is somewhat mitigated by field-level descriptions.

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 description coverage is 0%, so the description must compensate, and it does: it explains path resolution (server working directory, absolute path echoed), the uilog parameter format (XML scenario), and connection_id selection. The action parameter's enum is already in the schema, but the description adds semantics for each action. The only minor gap is not describing default behaviors when parameters are omitted.

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 first sentence states clearly what the tool does: record and replay UI scenarios. Each action is enumerated with its own specific verb and semantics. The scoring is 4 rather than 5 because it does not explicitly distinguish itself from sibling tools like tc_session or tc_form, though the resource (UI scenarios) is clear.

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

Usage Guidelines4/5

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

The description provides strong usage context: record_start/record_finish/run_scenario workflow is described in record_start and record_finish. It also notes that connection_id is required with multiple clients, and points to tc_session(action='list_connections') for finding connections. The only gap is the absence of explicit when-not-to-use guidance or alternative tools for similar tasks.

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

tc_sessionA

Connect to, launch or stop the 1C test client. In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. Actions:

  • connect(port*, host='127.0.0.1', version=null) Connect to a running 1C test client (started with /TESTCLIENT -TPort ). version is the platform version (e.g. '8.5.1.1343') and MUST match the running platform, else the handshake fails; if omitted a built-in default is used. Call this before any other tc_* tool. A different host/port creates another connection. The same host/port reconnects that client; its connection_id is retained, but find elements again before using them.

  • disconnect() Close the connection to the test client.

  • launch_client(base*, port=null, server=False, user=null, password=null, version=null, exe=null, extra_args=null, wait=30, connect=True) Launch a 1C test client and wait until it accepts connections on port, then optionally connect to it. base is a file infobase path (default), or 'server\infobase' when server=True. user/password — infobase credentials (optional; the password is passed on the command line and is visible in the OS process list). exe — full path to 1cv8.exe on Windows, or 1cv8/1cv8c on Linux (else env TC1C_PLATFORM_EXE or standard install path). Only the 1C platform executable is launched. Omit port to allocate a free local port. Each launch creates a separate connection_id. Linux requires access to a graphical session via the server's DISPLAY/XAUTHORITY environment. With connect=false ok means only that the port answers — the client can be up and showing an error, so check it before relying on it.

  • list_connections() List registered clients with connection_id, host, port, base, user and recording status. base/user are known for clients launched here; listing does not probe client health.

  • stop_client() Stop the test client started by launch_client in this connection, and disconnect from it. Unsaved changes may be lost. If stopping fails, retain the process so the call can be retried. connection_id selects the client. With several clients, connection_id is required. Use tc_session(action="list_connections").

ParametersJSON Schema
NameRequiredDescriptionDefault
exeNo
baseNo
hostNo
portNo
userNo
waitNo
actionYes
serverNo
connectNo
versionNo
passwordNo
extra_argsNo
connection_idNo

TDQS

A4.7/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 richly: the password is visible in the OS process list, stop_client may lose unsaved changes yet retains the process on failure for retry, version must match or the handshake fails, Linux needs DISPLAY/XAUTHORITY, and connect=false only proves the port answers. These are non-obvious operational traits an agent could not infer from the schema.

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?

The purpose is front-loaded followed by clearly delimited per-action blocks with required-parameter markers, which is the right structure for a 13-parameter multi-action tool. It is necessarily long, though a few lines (e.g. duplicating the default-port note) could be trimmed.

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

Completeness4/5

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

For a complex five-action connection manager with no annotations and no output schema, the description covers launch, connect, teardown, and failure semantics thoroughly. The residual gaps are the undocumented extra_args/wait parameters and the absence of any indication of what these calls return.

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 0%, so the description must compensate, and it does for most parameters — base/server path semantics, exe resolution order and platform defaults, version matching, and connection_id selection are all explained. Gaps remain for extra_args and wait (listed but not described), which are the only parameters lacking meaning beyond their names.

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

Purpose5/5

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

The description states a specific verb+resource ('Connect to, launch or stop the 1C test client') and disambiguates from siblings by mandating it be called before any other tc_* tool. The per-action breakdown (connect/disconnect/launch_client/list_connections/stop_client) lets an agent tell exactly which entry point to use.

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 gives explicit ordering ('Call this before any other tc_* tool'), routing ('Use tc_session(action="list_connections")'), and conditions ('With several clients, connection_id is required'). It also explains lifecycle rules such as a different host/port creating another connection and the same host/port reconnecting and retaining connection_id.

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

tc_tableA

Read and edit table or tree rows, manage selection and expand or collapse nodes. Choose action. Common operations for objects of this type live elsewhere: tc_field(action="is_visible"), tc_field(action="is_enabled"), tc_field(action="get_context_menu"), tc_app(action="get_parent"). In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. ok: true means the client accepted the command, not that anything changed — confirm an effect by reading the state back; target_check: present is not proof of one either. Where the address can be checked the response carries target_check: present, unknown (not checkable here) or off (checking disabled). target_hidden: true appears ONLY when the target exists and was NOT visible; it does NOT prove the absence of an effect — for tc_field(action="activate") invisibility is the normal precondition — it describes the ELEMENT itself and not an invisible container around it, and its absence says nothing. A wrong address is refused with an error only where the address can be checked: a read without a target marker cannot tell one from an empty answer, and tc_table(action="get_cell_text") on a table that does not exist returns text=null exactly as for an empty cell. Actions:

  • can_be_expanded(ref*, row_column=null, row_value=null) Whether a table row/group can be expanded. Pass row_column+row_value to target a specific row by a column name or title; omit them to use the current row. can_expand=true does not promise that tc_table(action="expand") will work: rows reporting true have been observed to stay collapsed. The reliable evidence is tc_table(action="expand")'s own value_before/value_after pair.

  • change_row(ref*) Start editing the current table row/column. Needs an existing row not already in edit mode.

  • choose_row(ref*) Choose (select / double-click) the current table row. In a choice form this picks the row and closes the form; in a list form the same action OPENS the row's item — on a hierarchical list, the folder own card rather than stepping into the folder. changed reports whether the ACTIVE WINDOW changed: true means a window opened or closed, which is what a completed choice looks like; false means the window stayed — the choice did not go through, or the row was picked without closing anything, so read the field you were filling to tell those apart.

  • collapse(ref*, row_column=null, row_value=null) Collapse a form group (Group[...]) or a table node. For a table, pass row_column+row_value to target a row by a column name or title; omit them for the current row. Nothing to collapse is not an error: ok only reports that the client accepted the command. changed is false only when value_before and value_after were both read and came back equal, which happens for a TABLE node, and null when they could not be read — a FORM GROUP (the platform's Expanded applies to tables only), a failed read, or readback='off'. can_be_expanded checks a table row, not a form group, and its true is not a promise: judge by value_before/value_after.

  • copy_row(ref*, confirm=null) Copy the current table row. On catalog/document lists a confirmation dialog may appear — set confirm=True/False to auto-answer it (default None: no dialog handling). (1C 8.3.25+)

  • delete_row(ref*, confirm=null) Delete the current table row. On catalog/document lists a 'delete?' dialog may appear — set confirm=True/False to auto-answer it (default None: no dialog handling). (1C 8.3.3+)

  • deselect_all_rows(ref*) Clear the table's row selection. Needs platform 8.5.1 or newer — on every earlier one the platform has no such method. Plain row navigation drops the selection down to the current row, which is the only way to undo a multi-row selection there. (1C 8.5.1+)

  • deselect_row(ref*) Remove the current table row from the selection. Needs platform 8.5.1 or newer — on every earlier one the platform has no such method. The closest thing there is to pass over the row with toggle_selection set: that toggles it, so a selected row becomes unselected. (1C 8.5.1+)

  • end_edit_row(ref*, cancel=False) Finish editing the current table row. Set cancel to discard the edits instead of committing them.

  • expand(ref*, row_column=null, row_value=null, subordinates=False) Expand a form group (Group[...]) or a table node. For a table, pass row_column+row_value to target a row by a column name or title; omit them for the current row. Set subordinates to also expand the child rows. Nothing to expand is not an error: ok only reports that the client accepted the command. changed is false only when value_before and value_after were both read and came back equal, which happens for a TABLE node, and null when they could not be read — a FORM GROUP (the platform's Expanded applies to tables only), a failed read, or readback='off'. can_be_expanded checks a table row, not a form group, and its true is not a promise: judge by value_before/value_after.

  • get_cell_text(ref*, column*) Read a cell in the current row. Text may include search-highlight markup. column is the column element NAME, or its 0-based index as a number or a string of digits ('0' is index 0, not a name — an element name cannot start with a digit). Unknown or ambiguous column names are refused; a matching title suggests the element name. Only displayed columns can be read. null does not establish that the cell is empty. A column inside a COLUMN GROUP that the table shows as one column may answer with the GROUP's text — a neighbouring column's value — and that answer cannot be told from a correct one; members of other kinds in the same group answer null instead.

  • get_current_item(ref*) Get the current item of a table → {ref}. ref: the table.

  • get_current_row(ref*) Get the current table row as [{column: value}]. Returns [] if there is no current row or its values could not be read. Needs platform 8.5.1 or newer — on every earlier one, use get_selected_rows after moving to the desired row, or get_cell_text to read one column. (1C 8.5.1+)

  • get_selected_rows(ref*) Get the selected table rows as a list of {column: value} maps, one per selected row, in LIST order — the current row is NOT put first, so do not read rows[0] as "the first row of the list". The keys are column TITLES; the column titled "Вид" can be EditField[ЮрФизЛицо], so match by title, not by name. Which columns a row carries is decided by the platform: a column missing from the answer does not mean the row has no value there, and an empty string is ambiguous — it can be a value the platform sent as empty or a filler for a column it did not send. Values may include search-highlight markup. (1C 8.3.6+)

  • go_one_level_down(ref*, row_column=null, row_value=null, column=null) Go one level down in a table tree. Pass row_column+row_value to target a specific row by a column value; row_column accepts a column name or title. Omit both to use the current row. Optional column names a column to read before and after the move; changed compares its cell text.

  • go_one_level_up(ref*, row_column=null, row_value=null, column=null) Go one level up in a table tree. Pass row_column+row_value to target a specific row by a column value; row_column accepts a column name or title. Omit both to use the current row. Optional column names a column to read before and after the move; changed compares its cell text.

  • goto_first_row(ref*, toggle_selection=False, column=null) Move to the first row of a table. Set toggle_selection to also toggle that row's selection. Pass column (the column element NAME) to have that cell read before and after the move: it comes back as value_before/value_after with changed=true when they differ. changed=false only means the two texts are the same — different rows can share a value; without column nothing is read and changed is null.

  • goto_last_row(ref*, toggle_selection=False, column=null) Move to the last row of a table. Set toggle_selection to also toggle that row's selection. Pass column (the column element NAME) to have that cell read before and after the move: it comes back as value_before/value_after with changed=true when they differ. changed=false only means the two texts are the same — different rows can share a value; without column nothing is read and changed is null.

  • goto_next_item(ref*) Move to the next item within a table. ref: the table.

  • goto_next_row(ref*, toggle_selection=False, column=null) Move to the next row of a table. Set toggle_selection to also toggle that row's selection. Pass column (the column element NAME) to have that cell read before and after the move: it comes back as value_before/value_after with changed=true when they differ. changed=false only means the two texts are the same — different rows can share a value; without column nothing is read and changed is null.

  • goto_previous_item(ref*) Move to the previous item within a table. ref: the table.

  • goto_previous_row(ref*, toggle_selection=False, column=null) Move to the previous row of a table. Set toggle_selection to also toggle that row's selection. Pass column (the column element NAME) to have that cell read before and after the move: it comes back as value_before/value_after with changed=true when they differ. changed=false only means the two texts are the same — different rows can share a value; without column nothing is read and changed is null.

  • goto_row(ref*, column=null, value=null, direction='down', toggle_selection=False, fields=null) Go to the table row where column equals value (int or string; the wildcards * and ? work). column is the column TITLE; an index is not accepted here. Pass fields ({column: value}) to match several columns at once. Seeks directly, so there is no need to walk rows. Matching is CASE-SENSITIVE and compares the value as SHOWN ("Встреча агента (Совещание)"), so a wildcard is often what you want. The search starts at the CURRENT row, runs in direction (down by default, or up) to the end of the list and does NOT wrap; the current row is itself a candidate, so searching for the value the cursor already sits on reports found=true without moving — step off the row first to find the NEXT match. A search that finds nothing still MOVES the cursor, to the last row going down, the first going up. Set toggle_selection to toggle the row it lands on; with no column and no fields it just toggles the current row. found is null when there was nothing to search for or the search result could not be determined — null never means "not found". In the answer criteria repeats the TITLE you searched by and observed.column gives that same column NAME. (1C 8.3.2+)

  • is_expanded(ref*, row_column=null, row_value=null) Whether a table row is expanded. Without row_column this reads the CURRENT row. Pass row_column (column name or title) and row_value to read another row without moving the cursor.

  • select_all_rows(ref*) Select all rows of a table. (1C 8.3.6+)

  • select_row(ref*) Add the current table row to the selection. Needs platform 8.5.1 or newer — on every earlier one the platform has no such method. Build a selection there by moving through rows with toggle_selection set — each row the cursor passes is toggled. (1C 8.5.1+)

  • set_cell_text(ref*, column*, text*) Set text in the current row's column (element name). Handles focus and row editing, then reads the result. Empty text clears the cell. Returns verified, changed and value_before/value_after. Numeric formatting can return verified=null with verification=numeric_equivalent. Continues an existing row edit, including a newly added row, and finishes it without discarding other cells' edits.

  • set_order(ref*, column*) Sort a table by a column, addressed by its TITLE. There is no direction parameter and no way to read the current direction: calling it again on the same column reverses the order. To learn which way it went, go to the first row and read a cell. (1C 8.3.6+)

  • switch_row_delete_mark(ref*, confirm=True) Toggle the deletion mark of the current row. Raises a modal 'mark for deletion?' dialog that is auto-answered: confirm=True → Yes (default), False → No. dialog_answered only reports that a modal question was answered — it is NOT evidence that the mark changed, and changed is always null here because the platform exposes no readable deletion-mark flag. To check the result, click the row's mark command and read the question text: 'mark for deletion?' means it is not marked, 'remove the mark?' means it is. (1C 8.3.6+)

  • table_add_row(ref*) Add a row to a form table. Fill its cells with set_cell_text using column element names. connection_id selects the client. Passing ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in ref. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
refNo
textNo
valueNo
actionYes
cancelNo
columnNo
fieldsNo
confirmNo
directionNo
row_valueNo
row_columnNo
subordinatesNo
connection_idNo
toggle_selectionNo

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and mostly does: it discloses that ok only means the client accepted the command, that target_check/target_hidden are weak signals, that can_be_expanded=true is not a promise, and per-action caveats (confirm dialogs, platform minimums, dialog_answered not being proof). It stops short of a general note on read vs write safety, but per-action coverage is unusually rich.

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

Conciseness3/5

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

The prelude is front-loaded and the per-action list is well organized, but the description is very long and several passages repeat verbatim (the collapse/expand caveat about value_before/value_after, the goto_* 'changed=false only means the two texts are the same' boilerplate). High information density is undercut by heavy repetition.

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

Completeness4/5

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

For a single mega-tool multiplexing 30 actions with 14 params, 0% schema coverage, no annotations and no output schema, the description covers invocation prerequisites, return-value interpretation and failure modes extensively. The main residual gap is that no output schema exists and return shapes are described prose-only per action, but the prose is sufficient for correct calls.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and does at length: column is a NAME or 0-based index ('an element name cannot start with a digit'), goto_row's column is a TITLE and rejects indices, direction defaults to 'down' and does not wrap, toggle_selection semantics, cancel=False default, confirm=None meaning no dialog handling, and the ref/connection_id relationship.

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

Purpose5/5

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

The opening sentence states a specific verb set and resource ('Read and edit table or tree rows, manage selection and expand or collapse nodes') and explicitly routes related operations to named siblings (tc_field, tc_app). Each of the 30 actions is documented with a distinct verb+object, so the agent can tell get_cell_text from get_selected_rows from goto_row unambiguously.

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?

Explicit when/when-not guidance abounds: cross-tool alternatives ('Common operations for objects of this type live elsewhere: tc_field(action="is_visible")…'), platform-version gates ('Needs platform 8.5.1 or newer — on every earlier one, use get_selected_rows…, or get_cell_text'), and per-action selection rules (row_column+row_value vs current row). Nothing is left to inference.

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

tc_windowA

Actions on the client application window. In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. Actions:

  • activate_window() Activate the current active window. (1C 8.3.3+)

  • answer_dialog(confirm=True, timeout=5) Answer a modal Yes/No question raised by the configuration. The question is an ordinary window and its buttons are picked by NAME: Button0 answers yes, Button1 answers no. A dialog may offer a THIRD choice (Button2 is often 'Отмена') which this action never presses — read question and inspect the window with tc_find(action="find_objects") when the answer you need is a different button. Waits up to timeout seconds for such a dialog to appear. Returns answered='Да'/'Нет' and question, or both null when no dialog showed up; question alone is null when the dialog carried no readable message. (1C 8.3.3+)

  • close_user_messages_panel() Close the window's user-messages panel. This is also how you tell which messages belong to which action: clear the panel, perform the action, then read the messages. (1C 8.3.6+)

  • close_window() Close the current active window. ok only says the close was accepted: the configuration may answer with a modal question ('Send the invitations?', 'Save the changes?') and leave the window open. Check with get_active_window afterwards. Also closes an active local print preview identified by get_active_window, returning to the underlying form. If the active window cannot be identified and local recovery is unavailable, returns code=active_window_unavailable without closing another window. (1C 8.3.3+)

  • execute_command(command*) Run a window command by name, or open an object by a navigation link. Both forms are accepted: a command-interface command name, and a link such as 'e1cib/list/Справочник.Контрагенты' (list), 'e1cib/app/Обработка.Имя' or 'e1cib/command/...'. The navigation link is usually how a scenario starts, since it opens a list or form without hunting through the command interface first. (1C 8.3.3+)

  • get_command_interface() Get the window's command interface → collection of buttons/groups. (1C 8.3.3+)

  • get_user_message_texts() Get the user-message texts shown in the window → list of strings. These ACCUMULATE over the session: a complaint from an earlier attempt is still listed after a later attempt succeeded. To judge one action, call tc_window(action="close_user_messages_panel") first, then the action, then this. (1C 8.3.3+)

  • goto_next_window() Ask for the next application window. The command is accepted, but no measurement has shown it switching anything: the platform runs it on the MAIN application window only, and that window is not addressable here. To go to another window, activate its form — tc_field(action="activate") on that window's ManagedForm ref, measured to work both ways. (1C 8.3.6+)

  • goto_previous_window() Ask for the previous application window. The command is accepted, but no measurement has shown it switching anything: the platform runs it on the MAIN application window only, and that window is not addressable here. To go to another window, activate its form — tc_field(action="activate") on that window's ManagedForm ref, measured to work both ways. (1C 8.3.6+)

  • goto_start_page() Ask for the start page. The command is accepted, but no measurement has shown it switching anything: the platform runs it on the MAIN application window only, and that window is not addressable here. To go to another window, activate its form — tc_field(action="activate") on that window's ManagedForm ref, measured to work both ways. (1C 8.3.6+) connection_id selects the client. With several clients, connection_id is required. Use tc_session(action="list_connections"). Returned references can be passed unchanged to actions that accept them. If a reference expires, find the element again.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYes
commandNo
confirmNo
timeoutNo
connection_idNo

TDQS

A4.4/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 richly: it discloses that goto_* actions cannot actually switch windows, that close_window's ok is only acceptance (modal questions can leave the window open), that user messages accumulate across the session, and that answer_dialog never presses a third button. These are non-obvious behavioral traits an agent must know.

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

Conciseness3/5

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

The action list is well-structured with per-action bullets, but several entries (goto_next_window, goto_previous_window, goto_start_page) repeat the same lengthy caveat verbatim three times, bloating the description. The core scoping and routing info is front-loaded and useful, but the redundancy hurts conciseness.

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

Completeness4/5

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

Given 5 parameters, no output schema, and no annotations, the description is quite complete: it documents each action's purpose, pitfalls, version requirements, and key parameters. Minor gaps remain (e.g., timeout units, return shape of get_command_interface), but overall it gives an agent what it needs to call correctly.

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 0%, so the description compensates substantially: it explains command's dual accepted forms (command name vs navigation link), answer_dialog's confirm/timeout semantics, and connection_id's role (required with multiple clients, via tc_session list_connections). It does not fully document every parameter's syntax, but adds significant meaning beyond the empty schema.

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

Purpose5/5

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

The description states a clear resource (client application window) and enumerates specific actions with verb+object semantics. It also distinguishes itself from siblings by routing callers to tc_find, tc_field, and tc_session for related operations.

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

Usage Guidelines4/5

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

The description provides explicit when-to-use guidance for ambiguous actions, notably routing goto_next_window/goto_previous_window/goto_start_page to tc_field(action="activate") and answer_dialog to tc_find when a different button is needed. It lacks explicit when-not-to-use the whole tool versus siblings, but the action-level routing is strong.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 10 tool updatesv1.0.0
    • First observedtc_app
    • First observedtc_calendar
    • First observedtc_doc
    • First observedtc_field
    • First observedtc_find
    • First observedtc_form
    • First observedtc_scenario
    • First observedtc_session
    • First observedtc_table
    • First observedtc_window

TDQS

A4.4/5.0

Scored across 10 tools

Disambiguation4/5

Tools are cleanly partitioned by UI object type (session, app, window, field, form, table, doc, calendar, find, scenario), and descriptions explicitly cross-reference where sibling actions live, e.g. 'tc_field(action="is_visible")' from tc_app. A few boundaries still blur — tc_app vs tc_window for window/app state, tc_app.get_child_objects vs tc_find, and tc_field vs tc_form for focus/activation — but the disambiguation notes on each tool substantially mitigate these.

Naming Consistency5/5

Every top-level tool follows the same tc_<noun> pattern (tc_session, tc_app, tc_window, tc_field, tc_form, tc_scenario, tc_find, tc_doc, tc_table, tc_calendar). Actions within each group are uniformly snake_case verb_noun (get_active_window, set_cell_text, goto_next_row), so the whole surface is predictable.

Tool Count5/5

Ten top-level tools is well-scoped for a UI-test-automation server; each namespace maps to a coherent domain (session lifecycle, app state, window, element kinds, discovery, recording) rather than duplicating a peer. The heavy per-group action lists are a deliberate dispatch pattern, not tool sprawl.

Completeness5/5

Coverage spans the full lifecycle: connect/launch/stop clients, inspect app and window state, read and edit every element kind (field, table, document, calendar), search the UI tree, and record/replay scenarios. Deprecated aliases are retained (get_area_text vs get_current_area_text), and no obvious end-to-end workflow dead-ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Acts as a bridge between AI agents (Claude, Cursor) and 1C:Enterprise databases, enabling metadata retrieval, configuration analysis, and code generation through natural language using the MCP protocol.
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Integrates AI agents with 1C:Enterprise databases via MCP and REST API, supporting a built-in HTTP server (no Python required) or a Python proxy mode.
    257
    GPL 3.0
  • F
    license
    A
    quality
    C
    maintenance
    Enables AI agents to interact with 1С:Enterprise and BAS ERP systems through REST and HTTP services, providing tools for searching catalogs, creating documents, and querying stock balances.
    6
    -