Skip to main content
Glama

tc_form

Control and inspect managed forms in 1C:Enterprise test clients: navigate elements, read focus, check modified status, execute choices, and wait for window closure.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNo
indexNo
actionYes
timeoutNo
window_titleNo
connection_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

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.