Skip to main content
Glama

write_form_fields_by_label

Fills multiple 1C form fields by matching their on-screen labels, types values Unicode-safe, and verifies each commit via readback.

Instructions

Write values into form fields located by their on-screen LABEL — CONFIG-AGNOSTIC, no per-field capture (generalizes write_form_value_xtest beyond a single fixed field). Foregrounds the form by open_link (e.g. e1cib/data/Справочник.Валюты create form), then TWO-PASS: pass 1 locate_text's every label and records its right edge; pass 2 clicks each field into the SHARED input column (rightmost label edge + input_column_gap) — so a short reference label like «Владелец» hits the same right-aligned column as the longest label instead of under-reaching into a neighbour — types the value Unicode-safe (xtest_type_unicode — Cyrillic-safe) -> Tab. (A field_mode="date" field clicks its own input mask at date_input_offset and types digit keys, never the calendar button; with 0/1 located labels the column falls back to the legacy label-center + input_offset.) Pairs with autofill_required_fields (feed its resolved {label->value} plan). save -> Ctrl+S (creates a record).

HONEST verification: after typing, the open form is value-READ on a fresh manager connection (readback, default on) and each item's committed is set True ONLY when the requested value is actually read back from the form model (the «стал равен» value-read) — a field targeted on screen but not read back is committed=False (no false positives). OData cannot verify here: a test-client-held file/server base is exclusively locked, so the protocol value-read of the SAME client is the verification, not assert_data.

PREREQ: client launched with an Xvfb display + matchbox. all_targeted = every label located + typed; all_committed = every targeted value read back. Returns {open_link, foregrounded, results:[{label, value, click_xy, targeted, committed, readback_value, geometry}], all_targeted, all_committed, readback:{opened, field_count, verified, fields}, screenshot}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNo127.0.0.1
portNo
saveNo
labelsYes
valuesYes
displayYes
readbackNo
open_linkYes
settle_secNo
field_modesNo
input_offsetNo
input_column_gapNo
readback_captionNo
date_input_offsetNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/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 behavioral burden and does so richly: the two-pass locate-then-click algorithm, the shared input-column geometry rule, the date field_mode branch, the save->Ctrl+S effect (creates a record), and the honest readback/committed semantics that avoid false positives. It even discloses the OData-can't-verify caveat and the Xvfb/matchbox prerequisite.

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 purpose is front-loaded, but the body is one dense monolith of backticked jargon and parenthetical asides rather than scannable structure. Much of the detail is justified by the tool's complexity, yet the phrasing is verbose enough that the signal is buried.

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 14-parameter, multi-step UI-automation tool, the description covers the prerequisite environment, the algorithm, the verification model, and the return-shape semantics (results/all_targeted/all_committed/readback). With an output schema present it correctly does not need to re-explain raw return values.

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% across 14 parameters, so the description must compensate, and it explains the semantics of the behavioral ones: field_mode='date', input_column_gap, date_input_offset, input_offset (legacy fallback), readback, and save. It leaves host, port, settle_sec, and readback_caption wholly unaddressed, so it does not fully close the coverage gap.

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 and resource ('Write values into form fields located by their on-screen LABEL') and immediately frames the differentiator: CONFIG-AGNOSTIC and generalizing write_form_value_xtest beyond a single fixed field. An agent can distinguish it from the sibling write_form_value_xtest 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 Guidelines4/5

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

Gives clear context (label-based, config-agnostic entry via open_link) and explicitly names a companion tool: 'Pairs with autofill_required_fields (feed its resolved {label->value} plan)'. It stops short of stating when NOT to use it versus write_form_value, write_form_values, or set_reference_field, so it is not a full when/when-not/alternatives rubric.

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