Skip to main content
Glama

tc_app

Inspect and control 1C application state: read active windows, child UI objects, session errors, performance counters, and file-dialog results; set action time limits for test client automation.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNo
clearNo
actionYes
resultNo
secondsNo
filenameNo
filter_indexNo
connection_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

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.