qa-mcp

write_form_value_xtest

Writes a value into 1C form object-attribute fields via protocol and XTEST input, committing with a real blur or optional save when pure protocol replay cannot.

Instructions

Write a value into a form field via the protocol+XTEST HYBRID — for OBJECT-attribute fields (Объект.* on catalog/document forms) that the pure protocol replay cannot commit.

The pure write_form_value only sets a field's edit-text; an object attribute commits only on a genuine user edit + blur, which a programmatic SetEditText does not trigger (and 1C exposes no AT-SPI elements). The 1C window IS OS-accessible, so this replays the capture's open+focus prefix (protocol, addresses field by name), then injects value via xdotool type (Unicode/Cyrillic-aware) into the focused client window on display, blurs (Tab -> commit), optionally saves (save=True -> Ctrl+S -> DB), and reads the value back by replaying the capture's read sequence. PREREQ: launch the client with launch_test_client(display=":89", port=…) (and a window manager so the form lays out — matchbox); display must be that Xvfb. Defaults match the demo capture (Справочник.Валюты.Наименование). Returns {field, value, committed, value_in_readback, readback_value, diverged_at, blurred, saved, display}.

Input Schema

TableJSON Schema

Name	Required	Default
`blur`	No
`host`	No	127.0.0.1
`port`	No
`save`	No
`field`	No	Наименование
`value`	Yes
`capture`	No	demo-write
`display`	No	:89
`read_frame`	No
`read_start`	No
`setup_stop`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 11, 2026

TDQS

A4.5/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 behavioral burden and does so richly: it describes the replay of open+focus, the xdotool type injection, blur/Tab commit, and the optional save=True -> Ctrl+S -> DB write side effect. It also discloses the readback sequence, the prerequisite environment, and the diverged_at mechanism for detecting failure, which goes well beyond what the schema exposes.

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 one-paragraph structure is front-loaded with the key differentiator and each sentence adds mechanism or prerequisite detail. It is on the verbose side with backticked internals, and restating the return dict is redundant against an existing output schema, so not a 5.

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?

For a tool this complex it covers prerequisites, mechanism, side effects, and the alternative, which is close to complete. The unannotated frame-index parameters and the return dict (already covered by the output schema) leave minor gaps, keeping it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% with 11 parameters, so the description must compensate and it only partially does. It clarifies field, value, save, display, and blur (Tab -> commit), but the frame-index parameters (read_start=25, read_frame=28, setup_stop=17) and capture remain unexplained, leaving several parameters documented nowhere.

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 (write), a specific resource (form field value), and the exact scope/mechanism (protocol+XTEST hybrid for OBJECT-attribute fields). It explicitly differentiates from the sibling write_form_value by naming why the pure-protocol version cannot commit. An agent can pick it apart from write_form_value 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 states when to use this (object-attribute fields like Объект.* that pure protocol replay cannot commit) and names the alternative it supersedes for that case (write_form_value). Prerequisites (launch_test_client with display, window manager) are spelled out, so the agent knows the required setup before invoking.

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

Deploy Server