Skip to main content
Glama

tc_app

Inspect and control 1C application state: read active windows, child objects, errors, dialogs, and limits; capture screenshots; set action timeouts; predefine file-dialog results.

Instructions

Application-level state: active window, child objects, errors, dialogs, limits. Also available: tc_field(action="is_visible"), tc_field(action="is_enabled"), tc_field(action="get_context_menu").

  • marks a required action parameter; the group schema treats action parameters as optional. Pass action="name" and only that action's parameters. Actions:

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

  • get_active_window() Read the active window: ref/class/title/platform_version, optional form_name/url/home_page/is_main. title is the form caption (null: no form or unreadable); url is empty without a link. form_name is a metadata name, not the form's GUID name; it is only attempted when the window supplies no caption and may remain absent; absence says nothing about the form. Read it explicitly with tc_app(action="get_child_objects") on the window ref. platform_version identifies this connection; unsupported actions report available_since. addressable=false means no element address, not a window type. native=true with recovery=close_window indicates a local preview to close before addressing form elements. active_window_unavailable gives recovery guidance; no_active_work_window requires opening a form with tc_window(action="execute_command"). (1C 8.3.3+)

  • get_child_objects(ref=null, scope='window') Read one level: parent and children: [...], with class/title and optional name/type/form_name. type is the platform element kind (null if unknown); ManagedForm.form_name is its metadata name. Omitted parent uses the last observed active window, querying it if none was observed. scope=application without a parent lists application windows. Windows/command buttons may include url; windows may include home_page/is_main. 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. Application messages (e.g. unfilled fields or posting refusal) are read with tc_window(action="get_user_message_texts"); they may include earlier actions. (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+)

  • get_screenshot(scale=100, grid=False, region=null) Capture the connected 1C window with popups as an image, without changing focus. Requires a local client on Windows or Linux with X11/XWayland and desktop access. scale: 25..100 percent. Optional region=[x,y,width,height] uses original screenshot pixels; grid labels those coordinates. capture_complete=false means some popups are missing. Screenshots are not recorded in scenarios.

  • set_file_dialog_result(result=True, filename=null, filter_index=0) Predefine the NEXT file dialog: result=true with filename (or a list for multiple files) selects; false cancels. filter_index is 0-based. Call BEFORE opening; cannot answer an open dialog. Each answer is consumed once. On 8.3.25+, replaces pending answers; clear_file_dialog_result clears unused ones. Older platforms cannot clear them: prepare only the next dialog. (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. ref selects the client; otherwise set connection_id when several clients are connected. Use tc_session(action="list_connections"). Success may omit target/connection echoes and shorten window details. Use returned references unchanged in ref; re-find expired elements.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNo
gridNo
clearNo
scaleNo
scopeNo
actionYes
regionNo
resultNo
secondsNo
filenameNo
filter_indexNo
connection_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • addedInput schema / properties / scope
      Added value: +{
      +  "default": null,
      +  "enum": [
      +    "window",
      +    "application"
      +  ],
      +  "title": "Scope",
      +  "type": "string"
      +}
  2. Changed4 schema fields changedv1.4.0
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "clear_file_dialog_result",
      -  "get_active_window",
      -  "get_child_objects",
      -  "get_current_error",
      -  "get_max_action_time",
      -  "get_parent",
      -  "get_performance",
      -  "set_file_dialog_result",
      -  "set_max_action_time"
      -]New value: +[
      +  "clear_file_dialog_result",
      +  "get_active_window",
      +  "get_child_objects",
      +  "get_current_error",
      +  "get_max_action_time",
      +  "get_parent",
      +  "get_performance",
      +  "get_screenshot",
      +  "set_file_dialog_result",
      +  "set_max_action_time"
      +]
    • addedInput schema / properties / grid
      Added value: +{
      +  "default": null,
      +  "title": "Grid",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / region
      Added value: +{
      +  "default": null,
      +  "items": {
      +    "type": "integer"
      +  },
      +  "title": "Region",
      +  "type": "array"
      +}
    • addedInput schema / properties / scale
      Added value: +{
      +  "default": null,
      +  "title": "Scale",
      +  "type": "integer"
      +}
  3. First observedv1.0.0

TDQS

A4.4/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 surprisingly well: it discloses platform prerequisites for get_screenshot (local client, Windows or Linux with X11/XWayland, desktop access), that capture_complete=false means popups are missing, that file-dialog answers are consumed once and cannot clear pre-8.3.25, that set_max_action_time is stored client-side with no network call, and that success responses may omit target/connection echoes. It still omits mutation risk details for clear_file_dialog_result beyond 'clears unused ones'.

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 structure is front-loaded (scope line, sibling pointers, the action=name convention) followed by a scannable per-action list, which is the right shape for a 10-action dispatcher. Some action entries, notably get_active_window, pack in dense parenthetical clauses that slow reading, but none are filler.

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 no-annotation, no-output-schema, 10-action tool, the description covers per-action behavior, return fields (ref/class/title/platform_version, parent/children structure, error/details), version gates (1C 8.3.3+ through 8.3.25+), and error-recovery hints. Nothing an agent needs to pick and invoke an action 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 description coverage is 0% with 12 parameters, so the description must compensate and largely does: ref is explained in get_child_objects/get_parent/set_max_action_time, scope='application' behavior is spelled out, scale is bounded (25..100), region is defined in original screenshot pixels, grid labels those coordinates, clear resets counters, filter_index is 0-based, and connection_id is tied to tc_session(action="list_connections"). A few parameters (seconds beyond 'max action-execution time', result defaults) are only lightly contextualized, so not a 5.

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 scopes the tool ('Application-level state: active window, child objects, errors, dialogs, limits') and each of the 10 actions carries a specific verb+resource, so an agent can see exactly which operations this dispatcher owns. It also names sibling tools it is not (tc_field for is_visible/is_enabled/get_context_menu, tc_window for get_user_message_texts, tc_find for subtrees), giving real differentiation.

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?

Routing is explicit in several places: application messages are read with tc_window(action="get_user_message_texts"), no_active_work_window requires tc_window(action="execute_command"), and a whole subtree needs tc_find(action="find_objects"). Per-action timing rules ('Call BEFORE opening; cannot answer an open dialog') give clear context. There is no single consolidated when-to-use/when-not statement for the tool as a whole, so it stops short of a 5.

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