Skip to main content
Glama

tc_window

Control the active 1C:Enterprise client window: activate or close it, run commands, answer Yes/No dialogs, and read user messages or the command interface.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
commandNo
confirmNo
timeoutNo
connection_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

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.